agentleFS
CyranoBCyranoB/web-forager/skills/fact-check/SKILL.md

fact-check

Skill10 starsChanged 57 days agoMITView on GitHub

Fact-check a specific, verifiable claim by seeking supporting and contradicting evidence, weighing source quality, and issuing a calibrated verdict with citations.

38 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use seo, research and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • nilssonrSkill

    seo

    Full SEO workflow for auditing pages and creating SEO-optimized content. Provides checklists with educational explanations aligned with Google Search Central documentation.

    Also in 3 projects that use this

  • NVIDIASkill

    research

    Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 13 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 31 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test a specific claim against evidence on both sides and issue a calibrated verdict.

    line 13
  2. Distinctive:

    Before using tools, read source-access.md completely.

    line 17
  3. Very specific:

    Use available web search and URL-fetch tools.

    line 19
  4. Very specific:

    If uvx cannot run packaged search, use ddgs without touching the current project environment:

    line 28
  5. Distinctive:

    If packaged page fetch fails, use Jina Reader:

    line 40
  6. Distinctive:

    Treat an unexpired forecast as a prediction with a horizon and assumptions.

    line 66
  7. Distinctive:

    Complete when: every factual claim has a testable meaning and temporal frame.

    line 70
  8. Distinctive:

    Search for primary evidence that would confirm each claim.

    line 75
  9. Distinctive:

    Complete when: every claim has received a genuine adversarial search, not merely a second confirming query.

    line 86
  10. Distinctive:

    Read enough decisive evidence for each atomic claim, starting with the strongest sources on both sides and expanding when a claim remains …

    line 91
  11. Distinctive:

    Complete when: every atomic claim has read evidence addressing its exact scope and time frame, or a named gap.

    line 99
  12. Distinctive:

    Stop when further searches repeat evidence without a realistic prospect of changing the verdict.

    line 101
  13. Distinctive:

    Default to a compact verdict for one claim:

    line 117
  14. Distinctive:

    add only caveats that could change how the verdict is understood.

    line 121
  15. Distinctive:

    Complete when: every extracted factual claim has a verdict, both search directions are accounted for, decisive evidence is cited, and …

    line 128

“Common” is measured: kept by at least 6 in 10 of the 31 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Fact Check

Test a specific claim against evidence on both sides and issue a calibrated verdict.

Tools

Before using tools, read source-access.md completely.

Use available web search and URL-fetch tools. Prefer callable names ending in duckduckgo_search and web_fetch; client-added prefixes vary, so inspect the tools in the session. Without session tools, run the packaged CLI in an isolated environment:

uvx --python '>=3.10,<3.14' web-forager search "your query" --max-results 8 --output-format json
uvx --python '>=3.10,<3.14' web-forager fetch "https://example.com" --format markdown

If uvx cannot run packaged search, use ddgs without touching the current project environment:

uv run --no-project --python '>=3.10,<3.14' --with 'ddgs>=9.5.2' python - <<'PY'
from ddgs import DDGS
results = DDGS().text(query="your query", max_results=8)
for r in results:
    print(r["title"], r["href"], r["body"])
PY

If packaged page fetch fails, use Jina Reader:

curl -s "https://r.jina.ai/https://example.com"

For a YouTube caption failure, report the access gap without forwarding the video URL.

The workflow requires both search and fetch. If either capability is unavailable, return UNVERIFIED and name the missing capability.

Workflow

1. Extract the claims

Turn the user's statement into specific, independently verifiable claims. Separate compound claims. If wording is subjective, explain that it can be contextualized but cannot receive a factual verdict. Continue immediately when the claim is clear; ask for confirmation only when two plausible interpretations would change the evidence sought.

Normalize each factual claim's entity, metric and units, population, geography, and relevant date where applicable. Preserve the original meaning and make material assumptions explicit. Establish whether the user wants publication-time evidence, a current assessment, or both; judge an explicitly historical statement at its stated date and label later developments separately. Otherwise use the current date as cutoff.

Treat an unexpired forecast as a prediction with a horizon and assumptions. Assess its support and likelihood; an unlikely prediction is not FALSE merely because its deadline has not arrived. Check its factual premises separately.

Complete when: every factual claim has a testable meaning and temporal frame; subjective statements and forecasts are distinguished from established facts.

2. Seek support

Search for primary evidence that would confirm each claim. Use direct paraphrases, official statements, and queries for the exact metric or event.

Complete when: each claim has the strongest available supporting evidence, or the absence of support is recorded.

3. Seek contradiction

Actively search for counterevidence, corrections, alternative measurements, and credible disagreement. Do not treat failure to find a debunk as confirmation.

Complete when: every claim has received a genuine adversarial search, not merely a second confirming query.

4. Read and weigh sources

Read enough decisive evidence for each atomic claim, starting with the strongest sources on both sides and expanding when a claim remains unsupported or disputed. A total source count is not a coverage criterion. Search snippets are discovery aids, not verdict evidence. Evaluate authority, specificity, recency, independence, and conflicts of interest. Trace corroborating reports to their underlying records: repeated publication of one study, release, or wire report is one evidence chain. Read the relevant methods, definitions, qualifications, and quotation context before drawing a conclusion.

Complete when: every atomic claim has read evidence addressing its exact scope and time frame, or a named gap; independence and material source limitations are explicit. Stop when further searches repeat evidence without a realistic prospect of changing the verdict; unresolved gaps remain UNVERIFIED rather than triggering invented support.

5. Deliver the verdict

Use this scale:

  • CONFIRMED: independent authoritative evidence agrees, or a definitive primary record directly establishes the exact fact; no credible contradiction survives review.
  • LIKELY TRUE: strong support remains, with minor gaps or caveats.
  • NEEDS CONTEXT: the core fact holds, but its scope, certainty, or significance is overstated. Explain the missing baseline or qualifier; use FALSE when the core fact fails.
  • UNVERIFIED: strong evidence is unavailable in either direction.
  • DISPUTED: credible sources materially disagree.
  • FALSE: strong evidence contradicts the claim and support is weak or absent.

Default to a compact verdict for one claim:

  1. state the claim and verdict first;
  2. explain the decisive support and contradiction in 2–4 sentences;
  3. add only caveats that could change how the verdict is understood;
  4. cite the decisive read sources, annotated by role; use only as many as needed.

For multiple extracted claims, repeat the compact block for each. Use a source-by-source account only when the user requests it or a material conflict cannot be explained compactly. State explicitly when one side produced no evidence.

Complete when: every extracted factual claim has a verdict, both search directions are accounted for, decisive evidence is cited, and confidence matches the limitations.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.