blog-fact-checking

fgrehm's avatarfrom fgrehm

Verify claims against referenced sources. Checks if blog content accurately represents external resources, APIs, or documentation.Trigger phrases: "fact check", "verify", "check claims", "verify claims", "check sources", "verify sources"

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 2, 2025
[Fact Checking]

When & Why to Use This Skill

This Claude skill provides automated verification of technical claims, API specifications, and configuration examples by cross-referencing official documentation and live web sources. It is designed to ensure the accuracy of technical content, prevent AI hallucinations, and maintain high editorial standards for blog posts and documentation.

Use Cases

  • Technical Blog Auditing: Automatically verify that version numbers, API endpoints, and library requirements mentioned in a draft match the latest official documentation.
  • Configuration Validation: Check if specific file paths, YAML/JSON structures, and configuration options provided in tutorials actually exist and follow the documented formats.
  • Performance Claim Verification: Cross-check optimization statistics, benchmark numbers, and system requirements against primary research papers or official vendor reports.
  • Quote and Attribution Accuracy: Ensure that direct quotes, technical specifications, and external references are precise, up-to-date, and correctly attributed to their original sources.
nameblog-fact-checking
description|
Trigger phrases"fact check", "verify", "check claims", "verify claims", "check sources", "verify sources"
allowed-toolsRead, WebFetch

Fact Checking

What to Verify

  • Claims about external tools/libraries
  • Version numbers and API details
  • Quotes and attributions
  • Technical specifications
  • Links match what's claimed in text
  • Configuration examples (file paths, formats, options)
  • Performance claims (optimization suggestions, benchmark numbers)

Process

  1. User directs what to check

    • "Check the Redis claim in paragraph 3"
    • "Verify the Vagrant version requirements"
    • "Is the systemd behavior I described accurate?"

  2. Fetch the source

    • Use web_fetch to get referenced documentation
    • Read official docs, not secondary sources when possible

  3. Compare claim vs source

    • Does the claim match what the source says?
    • Is version information current?
    • Are quotes/code examples accurate?

  4. Report findings

    • ✅ Verified: matches source
    • ⚠️ Outdated: source has changed
    • ❌ Mismatch: claim doesn't match source
    • 🚨 Hallucinated: config format/option doesn't exist in docs

Configuration Examples - Special Scrutiny

CRITICAL: Configuration examples are high-risk for hallucination. Before approving any config:

  1. Verify the file path exists in official docs

    • .tool-name/config.yml - does this file format exist?
    • config/settings.json - is this the documented path?

  2. Verify the configuration options

    • Are the option names exactly as documented?
    • Are the data types correct (array vs object vs string)?
    • Are nested paths correct?

  3. Check for deprecated formats

    • Has the config format changed in recent versions?
    • Are we showing old patterns that no longer work?

  4. Common hallucination patterns to watch for:

    • Inventing .hidden-dir/config.yml files
    • Creating YAML configs when tool uses TOML or JSON
    • Mixing up config locations (LSP init_options vs separate config files)
    • Assuming config file exists because directory exists (e.g., .ruby-lsp/ ≠ .ruby-lsp/config.yml)

Red flags:

  • "You can configure X via some/path.yml" without a documentation link
  • Config examples with TODO(@claude) markers still in them
  • Performance claims without measurements ("this reduces time by 50%")

Not Exhaustive

This is targeted checking, not an audit of every claim. User points to specific sections they want verified.

Example Workflow

User: "Check if I got the LightDM systemd behavior right in the 'Display Manager Symlink' section"

Action:

  1. Fetch systemd documentation on service types
  2. Fetch LightDM documentation if available
  3. Compare claim about "static" service type
  4. Report: Verified/Mismatch/Unclear

Response Format

**Checked**: LightDM systemd service behavior

✅ **Verified**: LightDM is indeed a "static" unit type requiring explicit symlink to display-manager.service

Source: systemd.unit(5) man page confirms static units cannot be enabled without symlinks.

**Note**: Minor point - the systemd docs use slightly different terminology but your explanation is accurate.

Tools

  • web_fetch for documentation
  • Always cite sources checked
  • Focus on technical accuracy, not writing style