# Documentation Verify

> Verifies documentation accuracy by cross-referencing claims, CLI commands, API signatures, and configuration against source code. Use when validating documentation correctness or checking code-docs consistency. Flags unsupported or outdated claims.

- Skill: `canonical/documentation-verify` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add canonical/documentation-verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/canonical/documentation-verify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: canonical (https://skillmd.com/u/canonical)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/canonical/documentation-verify

---


# Documentation Accuracy Verification

## Scope

Accuracy verification only: cross-reference documentation claims,
commands, API names, and configuration keys against repository evidence
in the same repository. Flag anything that cannot be verified.

In docs-only repositories, treat documentation tooling and artifacts
(for example, `conf.py`, `Makefile`, Sphinx configuration, redirects,
and examples) as the primary evidence source.

## Inputs

- Changed documentation files (from `git diff`).
  If `git diff` is unavailable or empty, use files explicitly provided
  for review; otherwise, treat all documentation files under the detected
  docs root as changed.
- Full repository artifacts relevant to documentation behavior.
- Test files and configuration schemas (when applicable).
- Documentation structure.

---

## Workflow

Follow this three-stage process to verify documentation accuracy:

### Stage 1: Discovery Scan

**Objective**: Identify documentation claims and form initial hypotheses.

1. Run `git diff` to list changed documentation files.
2. Categorize changes into claim types (behavior, CLI, API, config, examples, error messages, etc.).
3. Form initial hypotheses: Supported, Unsupported, Speculative, Ambiguous, or Outdated.

**For detailed categorization and hypothesis formation procedures**, see `references/verification_procedures.md` → Discovery Scan.

---

### Stage 2: Verification Pass

**Objective**: Verify every hypothesis with repository evidence.
Repository artifacts are the source of truth.

**CRITICAL**: Complete verification before reporting any claims.

1. Use **at least two search strategies** per claim (direct search, entrypoint tracing, test evidence, schema/validation search).
2. Apply claim-type-specific verification checklists (behavior, CLI, API, config, examples, errors, terminology).
3. Document evidence for each finding (file paths, line numbers, search commands).
4. Reclassify hypotheses based on verification results.
5. Apply false-positive prevention rules.
6. Cross-check documentation coverage.

**For comprehensive verification checklists and classification rules**, see `references/verification_procedures.md` → Verification Pass.

---

### Stage 3: Report Generation

**Objective**: Present verified findings with evidence and conservative recommendations.

1. Group findings by final classification (unsupported, outdated, incorrect, imprecise, speculative, inconclusive, no issues).
2. Format each finding using the standard template (doc claim, verification checklist, code evidence, assessment, recommended action).
3. Provide conservative change suggestions aligned with code reality.
4. Link to specific code artifacts (files, functions, structs, line numbers).
5. Integrate with other analysis findings (e.g., Diataxis compliance).

**For report formatting template and change suggestion guidelines**, see `references/report_format.md`.

---

## Constraints

- Complete the verification pass (Stage 2) before reporting any claims.
- Provide repository evidence for all documentation consistency claims.
- Repository artifacts are the source of truth: flag documentation that
  contradicts repository behavior, not vice versa.
- Do not claim documentation is "unsupported" without verification evidence
  (at least two search strategies with explicit search and no-match confirmation).
- Do not report false positives.
- Do not prefer "unsupported" when docs are vague or imprecise; use accurate classifications.
- Do not recommend changing implementation artifacts to match docs as the
  primary action; documentation should be adjusted to match repository reality.

## Output

Only verified findings with evidence make it to the final report. Do not include intermediate hypotheses or reasoning.