Choose your documentation audience
The audience changes which topics matter and how the documentation explains them. Choose the reader before reviewing the outline.
| Audience | Use it for |
|---|---|
| Internal technical docs | Architecture, component boundaries, operations and implementation understanding for your engineering team. |
| Developer onboarding | Helping a new engineer set up, understand key flows and make a first contribution. |
| End user docs | Product tasks, configuration, usage and troubleshooting for people using the product. |
| Internal API documentation | API implementation details and debugging context for backend teams. |
| External API documentation | Supported public endpoint contracts for developers integrating with your service. |
Internal technical docs is the default for new runs. Choose Developer onboarding when ramp-up is the priority; it deliberately avoids turning every source file into a reference page.
Add useful context
In your project description or instructions, explain who the reader is and what they need to achieve. For example: “These docs help a support engineer configure customer integrations. Explain the required fields and how to recognize a successful connection.”
Do not use audience instructions to invent features or guarantees that the source does not establish. External API documentation requires evidence that a contract is publicly supported; an internal handler alone is not enough.
Review the proposed scope
An end-user guide should not be dominated by class names or build internals. A developer onboarding guide should put setup and a few critical workflows before exhaustive reference material. Inspect the outline with those expectations before generating.
For an existing Space, review the audience options in Update Documentation Gaps. This guides subsequent work; it is not an automatic rewrite of every existing page.
Updated