What it does
/document generates documentation targeted to a specific type: inline docstrings or JSDoc, external API reference, user guides, or architecture documentation. It documents the why, not the what — code already shows what; documentation explains the reasoning behind it.
When to use
Use/document after implementing a new feature or API, when onboarding new team members to a system, when external consumers need API documentation, or when non-obvious design decisions need to be captured before context is lost.
Prerequisites
- The code, API, or system to document is implemented and stable — documenting moving targets produces stale docs
Conversation mode
Either mode works.What happens
1
Identify documentation type
The type is determined from your command (
--type inline|api|guide|architecture) or inferred from the target.2
Generate inline documentation (if applicable)
For functions, classes, and complex logic: language-appropriate inline docs are written (JSDoc for JS/TS, docstrings for Python). Each includes what the code does, parameters, return value, and a usage example.
3
Generate API reference (if applicable)
For external-facing APIs: endpoints, request/response formats, authentication, error codes, and examples are documented.
4
Generate user guide (if applicable)
For features users interact with: what it does, how to use it, common patterns, and gotchas are documented.
5
Generate architecture docs (if applicable)
For system components: purpose, dependencies, data flow, and deployment are documented.
Skills invoked
No skills are invoked./document is a direct workflow.
Documentation types
Usage
Documentation rules
- Document the WHY, not the WHAT (code shows what, comments explain why)
- Don’t document obvious things
- Keep docs close to the code they describe
- Update docs when code changes — stale docs are worse than no docs
Example
NotificationService and adds JSDoc:
Related commands
/explain
For explanations in conversation — /document produces persistent artifacts.
/review
/review checks that new behavior has tests; /document ensures it has docs.
/design
/design produces the architecture decision record that /document can formalize.
/improve
Maintainability improvements include documenting non-obvious decisions.