Verify documentation accuracy against source code

This skill reviews generated or changed documentation before it ships, applying the core principle that documentation is a set of checkable claims about a codebase, and its job is to check them. The rationale is grounded in published research: roughly half of AI answers to programming questions contain incorrect information, and models produce valid invocations for infrequent APIs barely a third of the time - yet the prose sounds equally authoritative either way, and readers can't tell verified docs from hallucinated ones without checking the source themselves.

It runs in three modes: guard-pass (the recommended default, verifying every claim after documentation has already been generated or edited), live mode (reading the actual implementation first, then documenting what it does, when invoked before writing), and review mode (walking a structured checklist against target docs to produce a findings report with file:line evidence, without rewriting unless asked). Before applying rules it adapts to the project - reading CLAUDE.md/AGENTS.md and any docs style guide (project conventions win on conflict), identifying which doc surfaces must move together (README, reference docs, docstrings, changelog, examples, config samples), and noting the project's version policy.

Ten rules split by severity. Must-fix accuracy rules: every referenced symbol (function, CLI flag, endpoint, config key, file path) must be verified against the actual source rather than recalled from memory; every code sample must actually run, with resolving imports and no hardcoded local paths or real credentials; documentation must describe the code's actual behavior, not its intended behavior, flagging any disagreement between code and spec rather than silently picking a side; and unverifiable claims like performance numbers or "production-ready" assertions need a repo source or they come out. Should-fix versioning rules require explicit version tagging (never "latest") and mandate that a code change touching documented behavior updates every doc surface that mentions it in the same change. Should-fix substance rules cut filler docstrings that just paraphrase a signature, forbid paraphrasing upstream docs (link instead, since paraphrases drift when upstream changes), and require examples to cover the failure path, not just the happy path. The worth-noting structure rule requires navigation, tables of contents, and internal links to actually resolve, with no "coming soon" stubs in published docs.

A mandatory self-check runs before delivery: every symbol verified this session (not from memory), every code sample checked to run clean, every number/claim backed by a repo source, docs grepped for old names after a code change, no restated-signature docstrings, and all links resolving. Review-mode findings use a fixed format:

**Rule N violation** in `docs/path.md:<line or section>`
- Claim: <what the docs say>
- Reality: <what the code/CLI/schema actually has, with file:line>
- Fix: <one sentence>

Use it reactively after an agent writes or updates READMEs, API references, docstrings, changelogs, or doc sites - or proactively in live mode before writing new docs. It explicitly does not review the code itself (that's clean-code-guard's jurisdiction - this skill reviews what the docs claim about the code), does not generate documentation strategy or information architecture from scratch, and does not enforce a prose style guide - tone belongs to the project, truth belongs to this skill.

Input is the generated or changed documentation plus the actual source it describes. Output is either corrected documentation (guard-pass/live mode) or a findings report with file:line evidence per violated rule (review mode).

It hands code-quality concerns to clean-code-guard and pulls from five companion reference files for verification procedure, code-sample rules, docstring rules, the review checklist, and citable sources.

Teams and agents shipping documentation who need every claim - symbols, code samples, version tags, performance numbers - verified against the actual source before it reaches readers who can't otherwise tell verified docs from hallucinated ones.