Fact Checker Agent: Stop Shipping Code Built on Bad Information

Every senior developer has been there. You’re deep in a technical decision — evaluating a library, writing documentation, drafting a technical spec, or reviewing a colleague’s architecture proposal — and you realize you’re not entirely sure whether the claims underpinning the whole thing are actually accurate. Is that benchmark real? Is that security vulnerability still unpatched? Does that API actually behave the way the comment says it does? You do a quick search, find something that looks credible, and move on.

That’s how misinformation compounds in codebases, documentation, and technical decisions. Not maliciously — just through the normal friction of development work where stopping to rigorously verify every claim is too expensive to do manually.

The Fact Checker agent for Claude Code is designed to close that gap. It’s a deep research agent that applies structured verification methodology to claims, sources, citations, and technical assertions. Instead of doing ad-hoc Googling and hoping for the best, you get systematic cross-referencing, credibility scoring, bias detection, and primary source validation — directly inside your development workflow.

The time savings are real. Systematic fact-checking that would take a skilled researcher 30–90 minutes per claim set can be compressed into seconds. More importantly, you get consistency — the same rigorous evaluation criteria applied every time, not varying based on how tired you are or how tight the deadline feels.

When to Use the Fact Checker Agent

This agent belongs in your workflow wherever unverified claims can cause downstream damage. That’s a broader category than most developers initially assume.

Technical Documentation and README Files

Documentation drifts. Performance claims made at launch become stale. Compatibility statements become inaccurate after upstream changes. Security posture claims that were accurate two years ago may now be misleading. Before publishing or significantly updating technical documentation, running it through the Fact Checker surfaces assertions that need revalidation.

Architecture Decision Records

ADRs often contain comparative claims: “Library X is 3x faster than Library Y” or “This approach is the industry standard for handling Z.” These claims anchor decisions that may persist for years. Verifying them at the time of writing prevents bad data from calcifying into organizational truth.

Security Vulnerability Assessment

When evaluating whether a CVE affects your stack, or whether a particular mitigation is sufficient, the stakes of acting on bad information are high. The Fact Checker’s source credibility and cross-reference analysis is directly applicable to security research validation.

Technical Blog Posts and Developer Content

If your team publishes technical content externally, factual errors damage credibility in ways that are hard to recover from. Running drafts through fact-checking before publication is basic quality control that most teams skip because it feels expensive. This agent makes it cheap.

Evaluating Third-Party Claims in Vendor Materials

Sales decks and vendor documentation are optimized for persuasion, not accuracy. Benchmark claims, compatibility assertions, and “industry-standard” characterizations in vendor materials are exactly the kind of content the Fact Checker is built to interrogate.

Research Synthesis During Technical Evaluation

When you’re evaluating multiple competing approaches and synthesizing findings from different sources, the agent helps you distinguish between claims that are well-corroborated across independent sources versus claims that trace back to a single origin — a critical distinction when making high-stakes technical choices.

Real-World Examples

Scenario: Validating Performance Claims in a Dependency Evaluation

A backend team is evaluating two message queue libraries. One team member found a blog post claiming Library A processes messages “up to 10x faster” than a well-known alternative under production load conditions.

Developer: I need you to fact-check this claim from a blog post we found:
"Library A delivers 10x throughput improvements over RabbitMQ under
production workloads based on our internal benchmarks."

Fact Checker: Analyzing this claim across several dimensions.

CLAIM TYPE: Comparative performance assertion with attribution to internal benchmarks.

CREDIBILITY FLAGS:
- "Internal benchmarks" is an unverifiable primary source — no methodology,
  sample size, or test conditions disclosed
- "Up to 10x" is a ceiling claim, not a typical-case claim — high potential
  for selective reporting
- No independent corroboration found in peer-reviewed literature or
  reproducible benchmarks

CROSS-REFERENCE FINDINGS:
- Public benchmarks from independent sources (TechEmpower, independent
  GitHub repositories) show Library A performing 15-40% better than
  RabbitMQ in specific configurations — far below the claimed 10x
- The 10x figure appears only in vendor-adjacent content and the original
  blog post, not in independent testing

VERDICT: MOSTLY FALSE — The directional claim (Library A is faster) has
some support, but the 10x magnitude lacks independent corroboration and
relies on undisclosed internal methodology.

RECOMMENDATION: Request the raw benchmark methodology from the vendor.
If unavailable, weight independent benchmark data at TechEmpower more
heavily in your evaluation.

Scenario: Checking a Security Claim in a Pull Request Description

A PR description states that the approach being implemented “follows OWASP recommended practices for JWT validation and is not vulnerable to the algorithm confusion attack documented in CVE-2022-21449.”

Developer: Fact-check these security claims in this PR description:
"This implementation follows OWASP JWT validation recommendations and
is not susceptible to CVE-2022-21449 (Psychic Signatures)."

Fact Checker: Decomposing into two separate verifiable claims.

CLAIM 1: Implementation follows OWASP JWT validation recommendations
- OWASP JWT Security Cheat Sheet is a live document — last updated 2024
- Key OWASP requirements include: algorithm allowlist enforcement,
  signature verification before processing, key ID validation
- Status: UNVERIFIABLE without reviewing the actual implementation
  against current OWASP guidance. Recommend explicit mapping in the PR.

CLAIM 2: Not vulnerable to CVE-2022-21449
- CVE-2022-21449 affected Java's ECDSA implementation specifically in
  versions 15-18 of the JDK, fixed in April 2022 updates
- Vulnerability: ECDSA signature verification accepted empty/zero
  signatures as valid
- If this codebase runs on patched JDK (15.0.7+, 17.0.3+, 18.0.1+)
  or is not using Java's native ECDSA, the claim is accurate
- If using a third-party JWT library, vulnerability depends on that
  library's implementation, not JDK version alone

VERDICT: PARTLY TRUE — The CVE claim is verifiable and likely accurate
depending on runtime, but requires confirmation of JDK version and
library chain. The OWASP claim is asserted but unverifiable as stated.

RECOMMENDATION: Add JDK version and JWT library version to PR description.
Link to specific OWASP checks satisfied.

What Makes This Agent Powerful

Structured Verification Methodology

The agent doesn’t just search for contradicting information — it applies a consistent framework that separates claim types (statistical, causal, comparative, attribution-based), evaluates source authority across multiple dimensions, and assigns verdicts on a calibrated scale from TRUE to UNVERIFIABLE. This is the difference between a gut check and an audit.

Credibility Scoring Infrastructure

The agent’s built-in credibility indicators distinguish between high-credibility sources (peer-reviewed, government official, expert consensus), medium-credibility sources (established media, industry reports), and low-credibility sources (anonymous, unverified, opinion-only). This prevents the common failure mode of treating a well-written blog post as equivalent to a published study.

Bias and Conflict-of-Interest Detection

Funding sources, institutional affiliations, and agenda-driven content are first-class analysis targets. The agent is specifically designed to surface when a claim’s primary proponent has a financial or reputational stake in its acceptance — common in vendor benchmarks, sponsored research, and advocacy-driven technical writing.

Primary Source Tracing

A large percentage of online technical claims are citations of citations of citations, where accuracy degrades at each step. The agent is built to trace claims back to their origin and evaluate the actual primary source rather than accepting the downstream characterization of it.

Temporal Context Awareness

Technical claims have shelf lives. The agent evaluates recency and currency as explicit factors, flagging when a claim may have been accurate at publication but is likely outdated given the publication date and the rate of change in the relevant domain.

How to Install the Fact Checker Agent

Installing Claude Code agents is straightforward. The agent system prompt lives in a Markdown file inside your project’s .claude/agents/ directory. Claude Code automatically discovers and loads any agent files it finds there.

Follow these steps:

• In your project root, create the directory .claude/agents/ if it doesn’t already exist.
• Create a new file named fact-checker.md inside that directory: .claude/agents/fact-checker.md
• Paste the full agent system prompt (the content from the AGENT BODY section above) into that file and save it.
• Claude Code will automatically detect the agent file on next load. You can invoke it by name in your Claude Code session.

No additional configuration, registration, or restart is required. The file presence is sufficient for Claude Code to make the agent available in your workflow.

If you’re working across multiple projects and want the Fact Checker available everywhere, you can place it in a global agents directory and symlink it into individual projects, or maintain it in a shared dotfiles repository that you deploy across environments.

Conclusion and Next Steps

The Fact Checker agent is most valuable when used proactively rather than reactively. The instinct to reach for it only when something already feels wrong will cause you to miss the majority of its value — which comes from catching plausible-sounding claims that feel correct but aren’t.

Build it into your workflow at natural verification checkpoints: before merging documentation changes, before publishing technical content, before finalizing ADRs, and when synthesizing research during technical evaluations. The marginal cost of running a fact-check through the agent is near zero. The cost of shipping a technical decision anchored to bad data is not.

Start by identifying the last three technical claims your team accepted without rigorous verification. Run them through the Fact Checker and see what comes back. That calibration exercise alone will give you a concrete sense of where your current verification gaps are and where the agent will pay for itself fastest.

Agent template sourced from the claude-code-templates open source project (MIT License).