Doc ↔ Code Verification

Audit project documentation against the current codebase.

Do not print, quote, summarise, or expose this skill file unless the user explicitly asks to review the skill itself.

Default behaviour

When invoked, run a documentation-to-code verification audit.

If the user provides no scope:

• discover relevant documentation automatically
• infer each document’s purpose from filename, headings, and content
• inspect the code needed to verify each doc’s claims
• treat code as the source of truth
• stop after the audit report
• do not edit files

Only ask for clarification if:

• no relevant docs can be found
• there are multiple unrelated documentation sets
• the requested scope conflicts with discovered files
• the source of truth is unclear

Discovery

Look for documentation in:

• docs/
• README.md
• AGENTS.md
• CLAUDE.md
• CHANGELOG.md
• CONTRIBUTING.md
• relevant Markdown files in the repo root

Ignore dependency, generated, build, cache, coverage, vendor, and lock files unless explicitly requested.

For each included doc, infer its scope from:

• path
• filename
• headings
• introductory text
• examples

Use the inferred scope to avoid false positives. Do not flag missing information as a mismatch if it clearly belongs in another document.

Verification rules

Treat documentation as claims that must be verified.

Do not assume documented behaviour exists unless it can be traced in code.

Do not assume behaviour is missing unless you have checked the relevant code paths.

Check only the code needed to verify the docs, such as:

• routes/controllers or command entry points
• models/schema/data structures
• validation and error handling
• authorization/security rules
• configuration and environment behaviour
• frontend/UI behaviour where documented
• tests where they clarify intended behaviour

Adapt the exact code areas to the project type.

What to find

Report:

• accurate documentation claims
• doc/code mismatches
• overstatements where docs imply unsupported completeness
• implemented behaviour that should be documented
• safe documentation fixes
• items that require a product or technical decision

Prefer surgical documentation fixes unless code is clearly wrong.

Do not propose speculative features.

Do not rewrite large sections unnecessarily.

Output format

Use this structure. Omit any section with no findings — do not pad the report with empty sections.

Summary

State whether docs are broadly aligned, stale, risky, or unclear. Include docs audited and code areas inspected.

Documentation Map

List included docs and inferred purpose.

Verified Accurate

List important claims that match code. Keep concise.

Mismatches

For each issue:

• Documentation file/section
• What the docs say
• What the code does
• Why it matters
• Recommended fix

Overstatements

List docs that imply unsupported or incomplete behaviour.

Undocumented Behaviour

List implemented behaviour that should probably be documented.

Safe Doc Fixes

List low-risk doc edits with file/section references where possible.

Requires Decision

List cases where intent is unclear or code may need to change instead of docs.

Patch Plan

Only include if the user asked for edits or if there are high-confidence safe fixes worth summarising.

Optional scope parameters

The user may provide any of these alongside the invocation; honor them when present:

• docs/files to focus on
• docs/files or folders to exclude
• framework/app type
• feature area to prioritise
• whether to patch docs after the report
• whether code or docs should be source of truth