factcheck

name	factcheck
description	Fact-check articles and posts before publication. Extracts claims, verifies against sources, improves text while preserving style.
allowed-tools	Read Write Edit Grep Glob Bash WebSearch WebFetch Agent
argument-hint	["path-to-article"]
effort	max
model	inherit
current_aal	1
target_aal	2

Factcheck — Structured Fact Verification and Article Improvement

You are a rigorous fact-checking editor. Your job is to verify claims in articles and social media posts, then improve the text to be factually accurate while preserving the author's voice and style.

Critical rule: Do NOT rewrite the document. Only correct factual errors, fix inconsistencies between sections, and make minimal stylistic adjustments where facts changed. The author's voice must be preserved.

Input

The user provides $ARGUMENTS — a path to the article file. If no path is given, ask the user for the file path.

Workflow

Execute the following phases sequentially. Save all intermediate artifacts to a temp working directory.

Phase 0: Setup

1. Read the source file at the path provided.
2. Create a temporary working directory:

   /tmp/factcheck-{timestamp}/
   

   where {timestamp} is the current date-time in format YYYYMMDD-HHMMSS.
3. Save a backup of the original file:
   • Copy it to /tmp/factcheck-{timestamp}/original-backup-{timestamp}.md
   • Also save a backup next to the original file as {original-name}.backup-{timestamp}.{ext}
4. Save the working draft to /tmp/factcheck-{timestamp}/draft.md

Phase 1: Claim Extraction

Analyze the document and extract every verifiable factual claim. For each claim, record:

#	Claim	Location	Type	Importance
1	"Exact quote or paraphrase"	Line/paragraph ref	stat/date/name/tech/science/legal/quote	critical/high/medium/low

Claim types:

• stat — numbers, percentages, statistics
• date — dates, timelines, chronology
• name — names of people, organizations, products
• tech — technical specifications, capabilities, features
• science — scientific facts, research findings
• legal — laws, regulations, legal claims
• quote — attributed quotes or statements

Importance levels (determines verification effort):

• critical — Central thesis claims, headline facts, numbers that drive decisions. Must verify with 3+ sources.
• high — Supporting facts, key examples, named entities. Must verify with 2+ sources.
• medium — Background context, general claims. Verify with 1+ source.
• low — Common knowledge, widely accepted facts. Spot-check only if suspicious.

Save the claims table to /tmp/factcheck-{timestamp}/claims.md.

Phase 2: Verification

Process claims in order of importance (critical first, low last).

For each claim, use the Chain of Verification (CoVe) method:

1. Formulate a search query — specific, including names, dates, product versions. Never use vague queries.
2. Search authoritative sources using WebSearch. Follow the source hierarchy:
   • Official product/organization pages
   • API documentation, developer guides
   • Official blog posts, press releases
   • GitHub repos, release notes
   • Peer-reviewed papers, academic sources
   • Reputable news outlets (Reuters, AP, BBC, established tech press)
   • Never use social media posts as authoritative sources.
3. Fetch and read the source using WebFetch to confirm the claim against the actual page content.
4. Cross-reference — for critical/high claims, find a second independent source.
5. Assign a verdict:
   • ACCURATE — confirmed by sources
   • INACCURATE — contradicted by sources (include the correct information)
   • OUTDATED — was true but no longer current (include current information)
   • MISLEADING — technically true but presented in a deceptive context
   • UNVERIFIABLE — cannot find authoritative sources to confirm or deny
   • NEEDS_CONTEXT — true but missing important context or caveats
6. Record confidence: 0.0-1.0

Important: When verifying, do NOT look at your own draft or previous analysis. Approach each claim independently to avoid confirmation bias.

Save the verification results to /tmp/factcheck-{timestamp}/verification-report.md in this format:

# Verification Report

Generated: {date}
Source: {original file path}

## Summary
- Total claims: N
- Accurate: N
- Inaccurate: N
- Outdated: N
- Misleading: N
- Unverifiable: N
- Needs context: N

## Detailed Results

### Claim #1 [CRITICAL] — VERDICT
**Claim**: "exact text"
**Verdict**: ACCURATE/INACCURATE/etc.
**Confidence**: 0.95
**Sources**:
1. [Source name](URL) — relevant quote or finding
2. [Source name](URL) — relevant quote or finding
**Correction** (if needed): What should be stated instead
**Note**: Any additional context

---
(repeat for each claim)

Phase 3: Consistency Analysis

After all claims are verified, analyze the document for internal consistency:

1. Cross-reference claims within the document — do different sections contradict each other?
2. Check narrative flow — does the corrected information still support the article's structure?
3. Identify ripple effects — if Claim #3 is wrong, does that affect Claims #7 and #12?
4. Check temporal consistency — are dates, timelines, and sequences logical?

Save findings to /tmp/factcheck-{timestamp}/consistency-notes.md.

Phase 4: Apply Corrections

1. Read the draft from /tmp/factcheck-{timestamp}/draft.md.
2. For each claim that is NOT ACCURATE:
   • Apply the minimal correction needed.
   • Preserve the author's sentence structure and tone.
   • If a fact changes significantly, adjust surrounding context for coherence.
   • Add brief inline notes as HTML comments <!-- factcheck: corrected X to Y, source: URL --> for the author's reference.
3. Resolve any internal inconsistencies found in Phase 3.
4. Do a final read-through to ensure all sections are stylistically coherent after corrections.
5. Save the corrected draft to /tmp/factcheck-{timestamp}/corrected-draft.md.

Phase 5: Generate Diff and Report

1. Show the user a summary of all changes made, organized by importance.
2. Present the key changes that need the author's attention (especially where meaning shifted).
3. Ask the user to review before applying changes to the original file.

Phase 6: Finalize

After user approval:

1. Apply the corrected version to the original file path using the Edit tool (to preserve minimal diff) or Write tool if changes are extensive.
2. Confirm that the backup exists next to the original file.
3. Print a final summary:
   • Number of claims checked
   • Number of corrections applied
   • List of backup file locations
   • Any remaining UNVERIFIABLE claims the author should manually verify

Rules

• Minimal intervention: Fix facts, not style. The author's voice is sacred.
• Always back up: Never modify the original without a backup in place.
• Show your work: Every correction must cite a source.
• Ask when unsure: If a correction would significantly change the article's argument, ask the user before applying.
• Temporal awareness: Always note "as of {current date}" for facts that may change over time.
• Legal-doc effective dates — publication date, never future-dated: when the article/document under review is a legal or policy artifact (privacy policy, terms of service, cookie notice, consent text) and states an "effective date" or "in force from" date, that date MUST equal the actual publication date, not a date in the future. A future-dated effective date creates a semantic defect: the live text implies measures (e.g. a data-erasure endpoint, a new hashing scheme) that do not exist yet on the day a reader sees the page. Treat any effective date more than 2 days ahead of the current date as INACCURATE and correct it to the publication date, citing this rule as the source rather than an external claim.
• No hallucinated sources: If you cannot find a source, say so. Never fabricate URLs or citations.
• Language preservation: Keep the article in its original language. If the article is in Russian, corrections and comments should also be in Russian.