Menu
Ensure every factual claim in a response is backed by verifiable evidence from the codebase, documentation, or external sources. Use when preparing technical documentation, code reviews, or any output where accuracy is non-negotiable.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Complete methodology for preventing AI hallucinations. Use when accuracy is critical and you need Claude to verify before claiming, cite before asserting, and admit uncertainty instead of guessing.
Forces every code-related claim to include file:line citations. No citation means the claim must be verified or removed. Use when building documentation, writing code reviews, or any output that others will rely on.
Assign confidence scores (0-100) to every claim in a response. Helps users understand which parts are verified facts and which are educated guesses. Use when the user needs to know how much to trust each part of the answer.
Forces Claude to extract exact quotes from files before making claims about them. Prevents hallucinations by grounding every statement in actual text from the codebase. Use when working with large files or unfamiliar code.
Verify every claim from multiple independent angles -- code, docs, tests, git history. Use when you need high confidence that something is correct before acting on it.
Multi-angle review of responses before delivery. Audits from 4 perspectives -- factual accuracy, logical consistency, completeness, and safety. Use for high-stakes responses where errors have real consequences.
| name | source-verifier |
| description | Ensure every factual claim in a response is backed by verifiable evidence from the codebase, documentation, or external sources. Use when preparing technical documentation, code reviews, or any output where accuracy is non-negotiable. |
Every claim must have a source. No source, no claim.
For every factual statement in your response, you must be able to point to where the evidence came from:
"The function at src/auth.ts:42 returns a Promise" Evidence: Read tool output from that file.
"validateToken is called in 3 places across the codebase" Evidence: Grep search results listing the files.
"The test suite has 142 passing tests" Evidence: Bash output from running the test command.
"According to the README, the API requires authentication" Evidence: README.md content.
"Based on the error handling pattern, this likely throws on invalid input" MUST be labeled as inference, not fact.
Good: "Looking at src/auth.ts:42-50, the validateToken function checks..." Good: "Based on package.json, the project uses express@4.18.2" Good: "Git blame shows this was last modified on 2026-02-15 by user@example.com"
Bad: "The function validates tokens" (no file reference) Bad: "You're using an old version of express" (no version cited) Bad: "This was recently changed" (no date or commit)
Before sending any response with factual claims:
[ ] Every file path mentioned actually exists (verified with Glob) [ ] Every function name is spelled correctly (verified with Grep or Read) [ ] Every code quote matches the actual file content (verified with Read) [ ] Every version number comes from package.json, not memory [ ] Every "this does X" claim was verified by reading the code [ ] Inferences are clearly labeled as inferences [ ] Uncertainties are clearly stated as uncertainties
Say exactly this: "I haven't verified this against the codebase. Let me check."
Then use your tools to check. Never skip this step to save time.
