| name | documentation |
| description | Use after behavior ships or an interface changes when documentation must be created, corrected, or verified against the source. |
| context | fork |
| agent | technical-writer |
This skill defines the documentation phase. Use the `technical-writer` agent when bounded documentation work can proceed independently; otherwise work locally. Verify commands, interfaces, and examples against shipped behavior.
Use lifecycle-documentation only when the result needs a durable artifact or handoff.
Document what actually shipped, not what was planned. Read the change, then write the docs a future engineer or agent needs: how to use it, how the interface behaves, and why the key decisions were made.
Docs are only done when they match the shipped behavior. Verify every command, signature, and example against the real code — guesses age into lies.
This skill is ship-time documentation — write the docs once a change lands. For the discipline of capturing decisions as they happen, and the ADR/README formats, see the documentation-and-adrs skill.
What to write
- README / usage — what it does, how to run it, a working example. Lead with the common path.
- API / interface docs — the public surface: signatures, parameters, return shapes, errors. Match the code exactly.
- ADRs — for decisions with lasting consequences: the context, the decision, the alternatives rejected, and the trade-off accepted.
Principles
- Match the source of truth. Pull examples and signatures from the real code; run commands you document.
- Why over what. Code shows what; docs explain why and how to use it. Don't narrate the obvious.
- Concise and current. Smallest doc that conveys it. Stale docs are worse than none.
What to produce
The files written or updated, and a note of anything you found undocumented but out of scope.
