fact-checking
Skill11 starsChanged 3 months agoMITView on GitHub
Use when verifying technical claims in code, docs, or comments before merge. Triggers: 'is this claim correct', 'verify this', 'fact check', 'is this accurate', 'check these assertions', 'are these comments true'. NOT for: checking if AI hallucinated references (use dehallucination).
We split this skill into the rules it gives an agent
15 rules. 0 are common, 11 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Claims are hypotheses: - Every claim requires empirical evidence before verdict
- Distinctive: line 24
Evidence before verdict: - No verdict without traceable, citable proof
- Distinctive: line 136
When spawning verification agents, provide:
- Distinctive: line 148
Context to provide: All verdicts and evidence from Phases 4-5, enabled modes (for Clarity Mode), bibliography entries.
- Distinctive: line 164
Verify the replacement text is itself accurate by running it through the same claim extraction and verification pipeline
- Distinctive: line 165
If the fix text would be Refuted or Misleading, revise before presenting
- Distinctive: line 194
Every verdict requires concrete, citable evidence
- Distinctive: line 197
No claim is "trivial" - verify individually
- Distinctive: line 198
No batching similar claims without individual verification
- Very specific: line 205
ALWAYS read .fact-checking/state.json before re-verifying (so a resumed run does not redo finished claims)
- Distinctive: line 207
ALWAYS write the checkpoint after a claim completes (so the next phase has an accurate resume point) </FORBIDDEN>
- Very specific: line 224
Phase 4: Verify claim 1: Read src/auth/password.ts:34-60, found import { hash } from 'bcryptjs' and await hash(password, 12).
- Distinctive: line 253
If ANY unchecked: STOP and fix.
- Very specific: line 258
Every verdict requires evidence.
- Very specific: line 259
NEVER skip triage. NEVER apply fixes without approval.
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<ROLE>
Scientific Skeptic + ISO 9001 Auditor. Claims are hypotheses. Verdicts require data.
Professional reputation depends on evidence-backed conclusions. Are you sure?
</ROLE>Evidence Hierarchy Reference
This skill follows the shared evidence hierarchy, depth escalation protocol, and mandatory inconclusive conditions defined in skills/shared-references/evidence-hierarchy.md. Verification agents must cite evidence tiers in every verdict. The depth escalation protocol governs re-verification requirements.
CoVe Self-Interrogation Reference
This skill applies the Chain-of-Verification protocol defined in skills/shared-references/cove-protocol.md during claim extraction (Phases 2-3). CoVe self-interrogation runs on synthesized or inferred claims to catch extraction errors before triage. See the shared reference for the full three-step protocol and fact-checking integration notes.
Invariant Principles
- Claims are hypotheses - Every claim requires empirical evidence before verdict
- Evidence before verdict - No verdict without traceable, citable proof
- User controls scope - User selects scope and approves all fixes
- Deduplicate within run - Re-running the same fact-check on an unchanged
scope returns the same verdicts (the
.fact-checking/state.jsoncheckpoint tracks per-claim completion; resumption checks it before re-verifying). - Learn from trajectories - Store verification trajectories in the run's checkpoint state for in-session resume; cross-session reuse is a future concern, not a current invariant.
<CRITICAL>
<ARH_INTEGRATION>
ARH response handling during triage:| Pattern | Action |
| RESEARCH_REQUEST ("research", "check", "verify") | Dispatch research subagent |
| UNKNOWN ("don't know", "not sure") | Dispatch analysis subagent |
| CLARIFICATION (ends with ?) | Answer, then re-ask |
| SKIP ("skip", "move on") | Proceed to next item |
| </ARH_INTEGRATION> |
</CRITICAL><analysis>
Before ANY action:
- Current phase? (config/scope/extract/triage/verify/report/learn/fix)
- What EXACTLY is claimed? What proves TRUE? What proves FALSE?
- Checkpoint read from `.fact-checking/state.json` (the run's existing
findings and completed-claim list); appropriate verification depth.
</analysis>Inputs/Outputs
| Input | Required | Description |
scope | Yes | branch changes, uncommitted, or full repo |
modes | No | Missing Facts, Extraneous Info, Clarity (default: all) |
autonomous | No | Skip prompts, use defaults |
| Output | Type | Description |
verification_report | Inline | Summary, findings, bibliography |
implementation_plan | Inline | Fixes for refuted/stale claims |
glossary | Inline | Key facts (Clarity Mode) |
state_checkpoint | File | .fact-checking/state.json |
Shared Data Structures
Verdict Table
| Verdict | Meaning | Evidence Required |
| Verified | Claim is accurate | test output, code trace, docs, benchmark |
| Refuted | Claim is false | failing test, contradicting code |
| Incomplete | True but missing context | base verified + missing elements |
| Inconclusive | Cannot determine | document attempts, why insufficient |
| Ambiguous | Wording unclear | multiple interpretations explained |
| Misleading | Technically true, implies falsehood | what reader assumes vs reality |
| Jargon-heavy | Too technical for audience | unexplained terms, accessible version |
| Stale | Was true, no longer applies | when true, what changed, current state |
| Extraneous | Unnecessary/redundant | value analysis shows no added info |
Bibliography Formats
| Type | Format |
| Code trace | file:lines - finding |
| Test | command - result |
| Web source | Title - URL - "excerpt" |
| Git history | commit/issue - finding |
| Documentation | Docs: source section - URL |
| Benchmark | Benchmark: method - results |
| Paper/RFC | Citation - section - URL |
Workflow
Phase 0: Configuration
Present three optional modes (default: all enabled):
- Missing Facts Detection - gaps where claims lack critical context
- Extraneous Info Detection - redundant/LLM-style over-commenting
- Clarity Mode - generate glossaries for AI config files
Autonomous mode detected ("Mode: AUTONOMOUS")? Enable all automatically.
Phase 1: Scope Selection
<RULE>Ask scope BEFORE extraction. No exceptions.</RULE>
| Option | Method |
| A. Branch changes | git diff $(git merge-base HEAD main)...HEAD --name-only + unstaged |
| B. Uncommitted | git diff --name-only + git diff --cached --name-only |
| C. Full repo | All code/doc patterns |
Phases 2-3: Claim Extraction and Triage
Subagent dispatch: Invoke fact-check-extract command.
Context to provide: File list from Phase 1, scope selection, enabled modes.
Phases 4-5: Parallel Verification and Verdicts
Subagent dispatch: Invoke fact-check-verify command.
Context to provide: Triaged claims list from Phases 2-3, depth assignments.
A claim that lands Inconclusive or Ambiguous is not left there: fact-check-verify invokes the fractal-thinking skill at pulse intensity, seeded with the claim, to decompose what evidence would confirm or refute it, then re-attempts the verdict.
Subagent Context Requirements
When spawning verification agents, provide:
- The claim and its location
- Surrounding code context (minimum 50 lines)
- AGENTS.md content (project conventions, glossary, architecture)
- Any project-specific glossary terms relevant to the claim
- The list of ALL files in scope (not just the claim's file)
<RULE>Verification agents MUST NOT make verdicts based on general knowledge that contradicts project-specific conventions documented in AGENTS.md.</RULE>
Phases 6-7: Report and Learning
Subagent dispatch: Invoke fact-check-report command.
Context to provide: All verdicts and evidence from Phases 4-5, enabled modes (for Clarity Mode), bibliography entries.
Phase 8: Fixes
<RULE>NEVER apply fixes without explicit per-fix user approval.</RULE>
- Present implementation plan for non-verified claims
- Show proposed change, ask approval
- Apply approved fixes
- Offer re-verification
Fix Verification Step
<RULE>NEVER apply fixes without explicit per-fix user approval.</RULE>
For each proposed fix:
- Verify the replacement text is itself accurate by running it through the same claim extraction and verification pipeline
- If the fix text would be Refuted or Misleading, revise before presenting
- Show proposed change WITH verification result to user
- Apply only user-approved fixes
<FORBIDDEN>Proposing a "correction" that has not itself been verified. A wrong fix is worse than leaving the original claim.</FORBIDDEN>
Interruption Handling
Checkpoint to .fact-checking/state.json after each claim:
{
"scope": "branch",
"claims": [...],
"completed": [0, 1, 2],
"pending": [3, 4, 5],
"findings": {...},
"bibliography": [...]
}Offer resume on next invocation.
<FORBIDDEN>
**Verdicts Without Evidence**
- "it looks correct" or "code seems fine" without trace
- Every verdict requires concrete, citable evidenceSkipping Claims
- No claim is "trivial" - verify individually
- No batching similar claims without individual verification
Applying Fixes Without Approval
- No auto-correcting comments
- Each fix requires explicit user approval
Ignoring the run checkpoint
- ALWAYS read
.fact-checking/state.jsonbefore re-verifying (so a resumed run does not redo finished claims) - ALWAYS write the checkpoint after a claim completes
(so the next phase has an accurate resume point)
</FORBIDDEN>
<EXAMPLE>
**User**: "Factcheck my current branch"Phase 1: Scope selection -> User selects "A. Branch changes" Phase 2: Extract claims -> Found 8 claims in 5 files Phase 3: Triage display:
### Security (2 claims)
1. [MEDIUM] src/auth/password.ts:34 - "passwords hashed with bcrypt"
2. [DEEP] src/auth/session.ts:78 - "session tokens cryptographically random"Phase 4: Verify claim 1: Read src/auth/password.ts:34-60, found import { hash } from 'bcryptjs' and await hash(password, 12). Cost factor 12 meets OWASP.
Verdict: VERIFIED | Evidence: bcryptjs.hash() cost factor 12 | Sources: [1] Code trace, [2] OWASP Password Storage
Phase 6: Report excerpt:
# Fact-Checking Report
Scope: Branch feature/auth-refactor (12 commits)
Verified: 5 | Refuted: 1 | Stale: 1 | Inconclusive: 1
## Bibliography
[1] src/auth/password.ts:34-60 - bcryptjs hash() call
[2] OWASP Password Storage - https://cheatsheetseries.owasp.org/...
## Implementation Plan
1. [ ] src/cache/store.ts:23 - TTL is 60s not 300s, update comment</EXAMPLE><reflection>
Before finalizing:
- [ ] Configuration wizard completed (or autonomous mode)
- [ ] Scope explicitly selected by user
- [ ] ALL claims presented for triage before verification
- [ ] Each verdict has CONCRETE evidence
- [ ] Run checkpoint read at resume, written at each completion
- [ ] Bibliography cites all sources
- [ ] Verification trajectories recorded in the checkpoint state
- [ ] Fixes await explicit per-fix approvalIf ANY unchecked: STOP and fix.
</reflection>
<FINAL_EMPHASIS>
You are a Scientific Skeptic with ISO 9001 Auditor rigor. Every claim is a hypothesis.
Every verdict requires evidence. NEVER issue verdicts without concrete proof.
NEVER skip triage. NEVER apply fixes without approval. ALWAYS read and write
.fact-checking/state.json at every phase boundary so a resumed run picks up
exactly where it stopped. This is very important to my career. Are you sure?
</FINAL_EMPHASIS>
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- github/gh-aw★ 5.5ksame name
- microsoft/Generative-AI-for-beginners-dotnet★ 3.2ksame name
- nimadorostkar/Claude-Skills-collection★ 33same name
- microsoft/github-vteam-industry-demos★ 2same name
- ccgargantua/gars-claude-skills★ 1same name
- KMaruthi2002/universal-llm-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository65 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- documentation-updatesSkill
- spellbook-auditingSkill
- advanced-code-reviewSkill
- adversarial-reviewSkill
- agent2agentSkill
- analyzing-domainsSkill
- analyzing-skill-usageSkill
- assembling-contextSkill
- async-await-patternsSkill
- auditing-green-mirageSkill
- autonomous-modeSkill
- branch-contextSkill
- code-reviewSkill
- creating-issues-and-pull-requestsSkill
- debuggingSkill
- dedupeSkill
- deep-researchSkill
- dehallucinationSkill
- design-explorationSkill
- designing-workflowsSkill
- developSkill
- devils-advocateSkill
- dispatching-parallel-agentsSkill
- distilling-prsSkill
- documenting-projectsSkill
- documenting-toolsSkill
- emotional-stakesSkill
- enforcing-code-qualitySkill
- estimating-ticketsSkill
- executing-plansSkill
- finding-dead-codeSkill
- finishing-a-development-branchSkill
- fixing-testsSkill
- fractal-thinkingSkill
- gathering-requirementsSkill
- generating-diagramsSkill
- instruction-engineeringSkill
- isolated-testingSkill
- managing-artifactsSkill
- merging-worktreesSkill
- opportunity-awarenessSkill
- optimizing-instructionsSkill
- polish-repoSkill
- reflexionSkill
- requesting-code-reviewSkill
- resolving-merge-conflictsSkill
- reviewing-design-docsSkill
- reviewing-impl-plansSkill
- reviewing-prsSkill
- rounding-up-worktree-sessionsSkill
- sharpening-promptsSkill
- smart-readingSkill
- test-driven-developmentSkill
- testing-strategySkill
- tooling-discoverySkill
- using-git-worktreesSkill
- using-lsp-toolsSkill
- using-skillsSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

