document-generate

Document Generate

Document Generate creates missing documentation for a codebase from the implementation up. It is for greenfield documentation coverage, not small doc touch-ups.

The organizing frame is Diataxis:

• Tutorial - get to a first successful result
• How-to - complete a specific task
• Reference - factual interface details
• Explanation - why the design works this way

When to Use

• A shipped feature has little or no documentation
• A module or subsystem needs first-pass docs from the source code
• A project needs documentation coverage beyond one README paragraph
• You need to decide which entities deserve tutorial, how-to, reference, and explanation docs

When NOT to Use

Instead of document-generate	Use
Updating docs after a code change	doc-update
Generating only deep API or interface reference docs, with no tutorial/how-to/explanation coverage	api-documentation
Creating VS Code CodeTour onboarding files	code-tour

Workflow

1. Define the scope and output mode

Choose one:

• one feature
• one module
• one subsystem
• the whole project

Then choose where the docs should land:

• inline updates to existing docs
• standalone docs in docs/
• both

If the scope is large, recommend starting with one feature or module first.

2. Do codebase archaeology before writing

Read enough source to understand reality:

• entry points and exported surface
• implementation files
• tests
• README, architecture docs, and contribution docs
• comments that explain design intent

The point is to document the code that exists, not the code you assume exists.

3. Partition the surface with Diataxis

Not every entity needs all four document types.

Use this rule of thumb:

Entity type	Tutorial	How-to	Reference	Explanation
End-user feature	Maybe	Yes	Maybe	Yes
CLI flag or config option	No	Yes	Yes	No
Public API or interface	No	Maybe	Yes	Maybe
Internal design concept	No	No	Maybe	Yes