From explain-this
Use before delivering any explainer, and whenever asked to fact-check, verify, or audit an explainer or article against its sources. Trigger phrases include "fact-check this explainer", "verify the claims", "check this article against its sources", "is this accurate", or reaching the end of researching or drafting an explainer. Applies both at research-time (are the gathered sources real and on-point?) and post-draft (does every claim trace to its cited source or, for code, the actual implementation?). Invoked directly or as a required gate by creating-explainers and explaining-codebases.
How this skill is triggered — by the user, by Claude, or both
Slash command
/explain-this:fact-checking-explainersThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
An explainer's authority comes from being right. A reader who catches one confident, wrong claim stops trusting the rest of the piece, figures and all. This skill makes "no incorrect claim ships" enforceable by tying every checkable claim to evidence you can point to. It is not a proofreading pass and not advisory: it is the gate an explainer passes before it is delivered.
An explainer's authority comes from being right. A reader who catches one confident, wrong claim stops trusting the rest of the piece, figures and all. This skill makes "no incorrect claim ships" enforceable by tying every checkable claim to evidence you can point to. It is not a proofreading pass and not advisory: it is the gate an explainer passes before it is delivered.
NO EXPLAINER SHIPS WITH AN UNVERIFIED FACTUAL CLAIM.
Every checkable claim either traces to a source that supports it, gets corrected to match the source, or gets cut.
No exceptions:
unsupported verdict. Find the source or cut the claim.Run this skill:
creating-explainers and explaining-codebases both call this skill at the gates above. When they do, the article is not done until this skill returns PASS.
When NOT to use: content that is not an explainer, or a pure opinion or editorial piece that makes no factual claims. (Most explainers make many factual claims. Default to running it.)
A checkable claim is a specific factual or empirical assertion:
Not checkable (do not flag these as factual claims):
Heuristic: if you are unsure whether something is a checkable claim, treat it as one and verify it. The cost of over-checking is small; the cost of a wrong claim shipping is the whole article's credibility.
file:line for code).supported.| Verdict | Meaning | Allowed at delivery? |
|---|---|---|
| supported | A source passage directly backs the claim | Yes |
| needs-source | Plausible but no citation yet | No - add a source or downgrade |
| unsupported | No source backs it | No - source it, soften, or cut |
| contradicted | A source says otherwise | No - correct it or cut it |
Research-time gate (inside creating-explainers research intake). Before drafting, go through the gathered sources and confirm each one exists and actually supports the points it will be used for. Fabricated, misremembered, or misread sources are cheapest to catch here, before they are baked into prose.
Post-draft gate (every explainer, before delivery). Audit every checkable claim in the finished article against its cited source. For codebase explainers, the source of truth is the real code. Every "this function does X", every quoted snippet, every architecture claim is checked against the actual implementation at a specific path and line. Code drifts; a snippet that was right yesterday may be wrong today.
At delivery, every checkable claim must be supported. For anything that is not, pick one:
needs-source into supported).Shipping with an unresolved needs-source, unsupported, or contradicted claim violates the Iron Law. There is no "ship it with a caveat" option for a factual claim you could not support.
Produce a claim-by-claim report plus an overall PASS/FAIL verdict. The exact format is in references/verification-report-format.md. The verdict is FAIL until every checkable claim is supported.
When invoked as a gate by another skill, return the report inline and do not let the article be delivered until PASS. When invoked directly by a user, present the report and offer to apply the fixes.
| Excuse | Reality |
|---|---|
| "I wrote it, so I know it's right" | You know what you intended. Verify what you actually wrote. |
| "It's a well-known fact" | Well-known facts are wrong often enough to check. It takes 30 seconds. |
| "The source probably says this" | Probably is not a verdict. Open the source and confirm. |
| "Close enough" | Numbers, dates, and names are exact or they are wrong. |
| "It's only one claim" | One confident wrong claim discredits the whole explainer. |
| "I'll flag it and let the reader decide" | The gate is your job, not the reader's. |
These thoughts mean stop and verify before the claim goes in:
| Mistake | Fix |
|---|---|
| Verifying that the citation exists, not that it supports the claim | Read the cited passage. A real source can still fail to back the claim. |
| Checking the easy claims, waving through the hard ones | The hard-to-verify claims are exactly where errors hide. |
| For code: trusting a comment, a function name, or a variable name | Read the implementation. Names and comments can lie; the code does not. |
Treating needs-source as shippable | needs-source is a to-do, not a pass. Resolve it. |
| Stopping at the first source that agrees | If sources disagree, that disagreement belongs in the article, not buried. |
npx claudepluginhub analyticalmonk/explain-thisCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.