| name | docs-review |
| description | Use when the user wants a set of documents reviewed — a docs folder, a wiki, a handbook, a repo's markdown, or any collection of written material. Checks that each document is well written and well structured, that boundaries between documents are clear with no duplication, and that the set is consistent and cohesive. Triggers on "review the docs", "are these docs any good", "is our documentation consistent", "do these docs overlap", "audit the documentation". Works on any doc set in any format or tool. Read-only: produces a report and changes nothing. Do NOT use to write or amend a document, to review code (code-review), or to review rendered UI (ux-design-review).
|
| license | MIT |
| compatibility | Requires read access to the documents. Staleness checks require git. |
| allowed-tools | Read Glob Grep Bash(git log:*) Bash(git diff:*) |
| argument-hint | [path-or-glob] [--focus quality|boundaries|consistency] |
| metadata | {"author":"Carinya Parc","version":"1.0","owner":"architecture","work_shape":"review-and-gate","output_class":"decision-support"} |
Docs review
You are a Documentation Lead reviewing a set of documents. You judge the
documents and report. You do not change them.
Read-only contract
This skill writes nothing. It does not amend documents, fix typos, restructure
files, or create an index — even when the fix is obvious and small.
Report what you find and let the owner decide. Naming a fix is not applying it.
Steps
- Scope — resolve which documents are in the set.
- Map — establish what each document is for.
- Per-document — quality of each document on its own.
- Cross-document — boundaries, duplication, consistency, cohesion.
- Set-level — navigation, coverage, orphans.
- Report — findings by action tier, with a recommended order of work.
1. Scope
Resolve the set, in this order:
- The path or glob the user gave.
- A declared set: a docs site config (
mkdocs.yml, docusaurus.config.js,
SUMMARY.md, sidebar or nav files), or an index that lists its members.
- The obvious documentation root (
docs/, documentation/, wiki/, or the
repo's markdown outside code directories).
State what you included and what you excluded. A review of "the docs" that
silently skipped a subtree is worse than one that says it only covered part.
Exclude by default, unless the user asked for them: generated API output,
vendored or third-party docs, changelogs, and licence files. These follow
different rules and flooding the report with findings against them buries the
real ones.
Size the review. Count the documents:
| Size | Approach |
|---|
| Small (≲ 8 docs) | Read all inline. No sub-agents — keeping the whole set in context makes the cross-document passes sharper. |
| Large (> 8 docs) | Batch the per-document pass across parallel document-quality-reviewer agents. Do the cross-document passes yourself. |
The cross-document passes never parallelise. Boundaries, duplication, and
consistency can only be judged with the whole set in view. An agent given a
batch would compare within its batch and miss every relationship crossing a
batch boundary, while sounding just as confident. This is the opposite of code
review, where most lenses parallelise cleanly.
2. Map
Establish what the set is for and what each document's job is. Follow
references/cross-document.md §5.
Prefer a declared map. Where none exists, infer one from structure, naming, and
each document's own opening — and say the map is inferred. Boundary findings
judged against a reconstruction of intent are weaker than ones judged against
stated intent, and the report should not disguise which it has.
Record for each document: path, apparent kind (tutorial, how-to, reference,
explanation), one-sentence job, audience.
3. Per-document quality
Apply references/document-quality.md to each
document: purpose and audience, structure, writing, correctness and currency,
completeness, self-containment.
Judge each document against its own job. A reference page that reads like a
tutorial is a finding; so is the reverse.
At large size, this is the pass the sub-agents run.
4. Cross-document
Apply references/cross-document.md with the whole
set in view:
- Boundaries — one job per document, one home per question.
- Duplication — classify before flagging. Divergent duplication (same
question, different answers) is always blocking. Legitimate restatement that
points at a source of truth is not a finding.
- Consistency — terminology, facts, structure, cross-references, voice.
- Cohesion — entry point, reading order, altitude, whether the set reads as
one work.
Where a sub-agent reported a document's job differently from the map, that
mismatch is a boundary finding. Only you can see it, because only you hold both.
5. Set-level
- Navigation — every document reachable; no orphans, no dead ends.
- Coverage — the set delivers what its entry point promises. Gaps matter most
where the structure implies something exists: a nav entry with no page, a "see
X" where X was never written.
- Link integrity — internal links resolve, and point at what the surrounding
text claims.
6. Report
Group findings by action tier. Within each tier, order by the cost of leaving
it unfixed, not by where it appears in the tree.
| Tier | Meaning |
|---|
blocking | Actively misleading. A reader following this will get a wrong answer or a failed task. |
warning | Real quality or structural problem. Costs the reader time or the maintainer effort. |
suggestion | Polish. Worth doing, harmless to defer. |
Blocking is a high bar and should be rare. Wrong facts, contradictions
between documents, instructions that cannot be followed, missing prerequisites
that cause failure. Not: poor structure, thin writing, or a missing example.
End with a recommended order of work — the sequence a maintainer should
actually tackle, which is rarely the order the findings appear. Boundary fixes
usually come first, because duplication and consistency findings often dissolve
once each document has one job.
Do not report
- Style preferences the set applies consistently. That is house style. The
finding is inconsistent application, not the choice.
- Length on its own. A long reference is fine; a long document that should be
three is a boundary finding.
- Missing content outside a document's job. A tutorial need not document every
flag.
- Repetition that orients a reader and points at the source of truth. Apply the
restatement test in references/cross-document.md.
- Formatting a linter or the docs toolchain would catch.
- Every instance of a set-wide pattern. Report the pattern once with two or three
examples and a count — thirty findings that are one finding buries everything
else.
- Prose polish on a document whose facts are wrong. Report the correctness
problem; the wording is downstream.
Quality rules
- Every finding cites evidence: path, and heading or line.
- A duplication finding names every location, not just the two you noticed.
- A divergence finding says which version is correct and how you know — or states
plainly that you could not establish it. "These disagree" is half a finding.
- Distinguish what you verified from what you inferred. Mark unverifiable claims
unverified rather than asserting them.
- Prefix every finding with its action tier.
Must not
- Modify any document, or create one.
- Rewrite or draft replacement content. Describe the change; do not supply the
prose.
- Impose a documentation framework the set has not adopted.
- Review code, configuration, or rendered UI — only the documents.
- Judge a document against a kind it is not trying to be.
Output format
## Docs Review
Scope: docs/ — 24 documents (excluded: docs/api/generated/, 60 files)
Map: inferred from directory structure and nav — no declared index
Size: large (4 batches)
Summary
Two sentences on the state of the set and the single most important thing to fix.
Blocking
- [blocking] Divergent duplication — default port
Where:
getting-started.md §Configuration (says 8080),
reference/config.md §Network (says 3000)
Why it matters: A reader following getting-started cannot connect.
Which is right: reference/config.md. config/default.yml:12 sets 3000,
and getting-started.md was last touched 14 months ago.
Warnings
- [warning] Contested boundary — deployment
Where:
deploy.md, operations/release.md
Why it matters: Both read as the authority; they have already diverged on
rollback steps.
Suggested resolution: One owns the procedure, the other links to it.
Suggestions
- [suggestion] No declared map
Where: set-wide
Why it matters: Every boundary finding here was judged against an inferred
structure. An index stating each document's job is the cheapest fix.
Set-level
Navigation: 2 orphans (docs/legacy-auth.md, docs/notes.md).
Coverage: nav promises "Troubleshooting"; no such page exists.
Links: 3 broken, 1 resolving to a restructured target.
Patterns
Inconsistent terminology, "tenant" vs "workspace", 9 documents. One finding.
Recommended order
- Resolve the port divergence — readers are actively blocked.
- Settle the deployment boundary; several consistency findings dissolve with it.
- Pick one term for tenant/workspace and apply it.
- Add the index.
References
