Skip to main content

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

Antigravity reads NotificationService and adds JSDoc:

/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.