Menu
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.
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.
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.
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.
| name | cross-checker |
| description | 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. |
Never trust a single source. Verify from at least two independent angles before accepting a claim as fact.
For any claim, check it against multiple sources:
Read the actual file. What does the code do? This is the strongest evidence.
What do the tests expect? Tests reveal intended behavior. If a test expects validateToken to return false for expired tokens, that's the designed behavior.
What was the original intent? Git blame and commit messages reveal why code was written. "commit abc123: fix token expiration check to reject tokens older than 24h"
README, comments, JSDoc, API docs. Do they match the code? If docs say one thing and code does another, the code is truth but the discrepancy matters.
Config files, environment variables, feature flags. Runtime behavior may differ from what the code looks like.
Package versions, API compatibility, deprecated features. A function might exist in the code but be broken due to a dependency update.
| Situation | Minimum angles needed |
|---|---|
| Stating a fact to the user | 1 (read the code) |
| Recommending a code change | 2 (code + tests or git history) |
| Security-related claims | 3 (code + tests + docs/config) |
| Production deployment advice | 3 (code + config + git history) |
| "This is safe to delete" | 3 (code + grep for references + tests) |
