Documentation Check
Rigorous quality gate for documentation. Focused on correctness, completeness, and comprehensiveness — not just voice and style.
Usage
/docs-check [focus]
Examples
/docs-check # Full quality gate
/docs-check focus on code examples # Verify examples run
/docs-check check API completeness # Parameter coverage
/docs-check are all links valid? # Link check
/docs-check just the Quick Start # Section-specific
Arguments
Focus: $ARGUMENTS
Use arguments to narrow the scope:
| Argument Type |
Example |
Behavior |
| Section name |
just the Quick Start |
Audit only that section |
| Quality dimension |
focus on correctness |
Prioritize that checklist |
| Specific question |
are the code examples runnable? |
Answer directly with evidence |
| None provided |
(empty) |
Run full checklist across all dimensions |
Verification Checklist
Work through each dimension. For each item, document: PASS/FAIL + evidence.
Correctness (accuracy)
| Check |
How to Verify |
| Code examples run |
Extract and execute each example. Report errors verbatim. |
| API signatures match |
Compare documented signatures against source code. |
| Links resolve |
Check each link target exists (relative paths, anchors, URLs). |
| Technical claims accurate |
Cross-reference against implementation or authoritative source. |
| Versions current |
Verify version numbers match package.json, Cargo.toml, etc. |
Completeness (nothing missing)
| Check |
How to Verify |
| Required sections present |
Compare against applicable template (README, API ref, guide). |
| Parameters documented |
Each param has: type, purpose, constraints, default value. |
| Error scenarios covered |
Document what happens when things go wrong. |
| Edge cases addressed |
Empty inputs, nulls, boundaries, concurrent access. |
| Success and failure examples |
Show both happy path and error handling. |
Comprehensiveness (depth)
| Check |
How to Verify |
| Common use cases |
List 3-5 typical scenarios; verify each is addressed. |
| Migration paths |
Breaking changes include upgrade instructions. |
| Cross-references |
Related docs linked where helpful. |
| Agent-friendly |
Structured for AI consumption (clear headers, examples). |
| Troubleshooting |
Common issues and solutions documented. |
Execution
- Identify target — What documentation is being checked?
- Run checks — Work through the checklist, executing verification steps
- Collect evidence — Note specific line numbers, error messages, missing items
- Classify issues — Blocking (must fix) vs. suggestions (nice to have)
- Report — Structured output per format below
Output Format
# Documentation Check: {doc-name}
**Verdict**: PASS | NEEDS WORK | BLOCKED
**Blocking issues**: {count}
**Suggestions**: {count}
## Blocking Issues (must fix)
1. **{Check name}**: {Issue description}
- Location: {file:line or section}
- Evidence: {error message, mismatch, etc.}
- Fix: {specific action to resolve}
## Suggestions (nice to have)
1. {Improvement with rationale}
## Passed Checks
- {List of checks that passed}
## Summary
{One sentence: ready to publish or what must be addressed first}
When to Use
- Before merging documentation PRs
- Before publishing READMEs to new packages
- Quarterly documentation audits
- After major feature changes
Relationship with docs-review
For combined voice/style and technical verification, load both this skill and the internal:docs-review skill.
| Dimension |
docs-review |
docs-check |
| Focus |
Voice, style, structure |
Correctness, completeness |
| Question |
"Does it sound right?" |
"Is it accurate and complete?" |
| Approach |
Subjective assessment |
Objective verification |
| Output |
Editorial feedback |
Pass/fail with evidence |
| Speed |
Quick pass |
Thorough audit |
When to use each:
- docs-review — Polishing prose, checking tone, improving flow
- docs-check — Quality gate before merge, verifying technical accuracy
- Both — Full documentation audit (load both skills)
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: docs-check-43description: Rigorous quality gate for documentation before merge or publish. Verifies code examples run, links resolve, APIs match implementation, and all sections are complete. Use when auditing docs, reviewing documentation PRs, or when "verify", "quality gate", "docs audit", or "check examples" is mentioned. Use when this capability is needed.4---56# Documentation Check78Rigorous quality gate for documentation. Focused on correctness, completeness, and comprehensiveness — not just voice and style.910## Usage1112```13/docs-check [focus]14```1516### Examples1718```19/docs-check # Full quality gate20/docs-check focus on code examples # Verify examples run21/docs-check check API completeness # Parameter coverage22/docs-check are all links valid? # Link check23/docs-check just the Quick Start # Section-specific24```2526## Arguments2728**Focus**: $ARGUMENTS2930Use arguments to narrow the scope:3132| Argument Type | Example | Behavior |33|---------------|---------|----------|34| Section name | `just the Quick Start` | Audit only that section |35| Quality dimension | `focus on correctness` | Prioritize that checklist |36| Specific question | `are the code examples runnable?` | Answer directly with evidence |37| None provided | (empty) | Run full checklist across all dimensions |3839## Verification Checklist4041Work through each dimension. For each item, document: PASS/FAIL + evidence.4243### Correctness (accuracy)4445| Check | How to Verify |46|-------|---------------|47| Code examples run | Extract and execute each example. Report errors verbatim. |48| API signatures match | Compare documented signatures against source code. |49| Links resolve | Check each link target exists (relative paths, anchors, URLs). |50| Technical claims accurate | Cross-reference against implementation or authoritative source. |51| Versions current | Verify version numbers match package.json, Cargo.toml, etc. |5253### Completeness (nothing missing)5455| Check | How to Verify |56|-------|---------------|57| Required sections present | Compare against applicable template (README, API ref, guide). |58| Parameters documented | Each param has: type, purpose, constraints, default value. |59| Error scenarios covered | Document what happens when things go wrong. |60| Edge cases addressed | Empty inputs, nulls, boundaries, concurrent access. |61| Success and failure examples | Show both happy path and error handling. |6263### Comprehensiveness (depth)6465| Check | How to Verify |66|-------|---------------|67| Common use cases | List 3-5 typical scenarios; verify each is addressed. |68| Migration paths | Breaking changes include upgrade instructions. |69| Cross-references | Related docs linked where helpful. |70| Agent-friendly | Structured for AI consumption (clear headers, examples). |71| Troubleshooting | Common issues and solutions documented. |7273## Execution74751. **Identify target** — What documentation is being checked?762. **Run checks** — Work through the checklist, executing verification steps773. **Collect evidence** — Note specific line numbers, error messages, missing items784. **Classify issues** — Blocking (must fix) vs. suggestions (nice to have)795. **Report** — Structured output per format below8081## Output Format8283```markdown84# Documentation Check: {doc-name}8586**Verdict**: PASS | NEEDS WORK | BLOCKED87**Blocking issues**: {count}88**Suggestions**: {count}8990## Blocking Issues (must fix)91921. **{Check name}**: {Issue description}93 - Location: {file:line or section}94 - Evidence: {error message, mismatch, etc.}95 - Fix: {specific action to resolve}9697## Suggestions (nice to have)98991. {Improvement with rationale}100101## Passed Checks102103- {List of checks that passed}104105## Summary106107{One sentence: ready to publish or what must be addressed first}108```109110## When to Use111112- Before merging documentation PRs113- Before publishing READMEs to new packages114- Quarterly documentation audits115- After major feature changes116117## Relationship with docs-review118119For combined voice/style and technical verification, load both this skill and the `internal:docs-review` skill.120121| Dimension | docs-review | docs-check |122|-----------|-------------|------------|123| **Focus** | Voice, style, structure | Correctness, completeness |124| **Question** | "Does it sound right?" | "Is it accurate and complete?" |125| **Approach** | Subjective assessment | Objective verification |126| **Output** | Editorial feedback | Pass/fail with evidence |127| **Speed** | Quick pass | Thorough audit |128129**When to use each:**130131- **docs-review** — Polishing prose, checking tone, improving flow132- **docs-check** — Quality gate before merge, verifying technical accuracy133- **Both** — Full documentation audit (load both skills)134135---136> Converted and distributed by [TomeVault](https://tomevault.io/claim/outfitter-dev) — claim your Tome and manage your conversions.137<!-- tomevault:4.0:skill_md:2026-04-14 -->
tomevault-io