/spec-docs¶
Generate user-facing documentation from the spec and implemented code. Produces API references, user guides, architecture decision records (ADRs), and operations runbooks depending on the type of feature built.
Usage¶
Arguments¶
| Argument | Required | Description |
|---|---|---|
spec-name |
No | Name of the spec to document. Auto-detected if only one spec exists. |
What It Does¶
-
Locates the spec and reads spec files alongside the actual implementation code.
-
Detects the feature type and determines which documents are appropriate:
| Feature Type | Documents Generated |
|---|---|
| API / Backend | API Reference, ADR |
| UI / Frontend | User Guide, Component Reference |
| Full-Stack | All of the above |
| Library / SDK | API Reference, Getting Started guide |
| Infrastructure | Runbook, ADR |
-
Asks for confirmation — shows the detected type and planned documents, then lets you approve, choose specific docs, or specify a custom output location.
-
Generates documentation — reads the actual implementation as the source of truth (not just
design.md), so the output reflects what was actually built. Default output location:.claude/specs/<feature-name>/docs/. -
Reports results — lists all generated documents with brief descriptions and highlights any discrepancies between
design.mdand the actual implementation found during generation. -
Offers next steps — move docs to the project's
docs/folder, regenerate specific documents, or mark them for manual editing.
Example¶
Tips¶
- Run this after
/spec-acceptfor the most accurate documentation — you know exactly what shipped. - The generated docs are a strong starting point for accuracy and structure, but may need tone and voice editing before publishing.
- ADRs are especially valuable for future developers who need to understand why decisions were made — do not skip them for complex features.
- If the implementation diverged from
design.md, the discrepancies report tells you exactly where.
Note
Documentation is generated from actual code, not just the spec. If the implementation is incomplete or differs from the design, those differences will appear in the output.
See Also¶
- /spec-accept — Complete acceptance testing before generating docs
- /spec-release — Generate release notes alongside documentation
- /spec-retro — Capture lessons learned after the feature ships