doc-maintenance

Topics in the source

• Doc Maintenance Skill
• When to Use
• Target Documents
• Workflow
• Step 1 — Detect what changed
• Step 2 — Classify changes
• Step 3 — Build a change summary
• Step 4 — Audit each target doc

Detect documentation drift and fix it via PR — no rewrites, no churn. Periodic doc review (e.g. weekly or after releases) After major feature merges When asked "are our docs up to date?" When asked to audit README / SPEC / PRODUCT accuracy | Document | Path | What matters | |----------|------|-------------| | README | README.md | Features table, roadmap, quickstart, "what is" accuracy, "works with" table | | SPEC | doc/SPEC.md | No false "not supported" claims, major model/schema accuracy | | PRODUCT | doc/PRODUCT.md | Core concepts, feature list, principles accuracy | Out of scope: DEVELOPING.md, DATABASE.md, CLI.md, doc/plans/, skill files, release notes. These are dev-facing or ephemeral — lower risk of user-facing confusion. Find the last review cursor: Then gather commits since the cursor: Scan commit messages and changed files. Categorize into: Feature — new capabilities (keywords: feat, add, implement, support) Breaking — removed/renamed things (keywords: remove, breaking, drop, rename) Structural — new directories, config changes, new adapters, new CLI commands Ignore: refactors, test-only changes, CI config, dependency bumps, doc-only changes, style/formatting commits. The

This is an excerpt. Refer to the complete source and its current requirements.