What this prompt does
This prompt builds an AI-driven documentation pipeline for a [language] project with [component_count] components, targeting [audience] and following [doc_standard] conventions. Instead of asking for one document, it defines seven generation steps, each with prompts tuned to a different documentation artifact — so the output is a repeatable system, not a one-off page.
The structure works because each step feeds the model the right source signal. Module docs come from source files; the architecture overview comes from directory structure, config files, and the dependency graph; API reference for [api_count] endpoints comes from route definitions and response schemas, rendered in [doc_format]. A getting-started guide walks a new developer through setup including [env_vars], a glossary is mined from model and enum names, and a troubleshooting section is derived from real error-handling patterns. The final step — a freshness checker that compares source and doc modification dates — is what keeps the whole set from rotting after the first pass.
When to use it
- You have undocumented or thinly documented code across
[component_count]modules. - You need an API reference for
[api_count]endpoints generated from real route definitions. - You want an architecture overview that matches the actual directory and dependency structure.
- You are onboarding new developers and need a reliable getting-started guide.
- You want docs structured to a standard like
[doc_standard]rather than ad hoc. - You need a way to detect when documentation has gone stale.
Example output
Expect a pipeline of prompts plus their intended outputs, not a single page. The first stage yields per-module documentation listing the public API, parameter descriptions, side effects, and a usage example for each module. The architecture stage produces a high-level diagram description, a component interaction map, and a data-flow narrative. From there you get API reference entries in [doc_format] with request and response examples, a getting-started guide covering cloning, dependency install, and [env_vars], a domain glossary mined from model and enum names, a troubleshooting section keyed to common failure modes, and a freshness-checker script that flags any doc older than the source it describes.
Pro tips
- Feed the architecture step the real directory tree and dependency graph; its accuracy depends entirely on that input.
- Set
[doc_format]to match your toolchain (for example Markdown with OpenAPI specs) so the API reference drops straight into your docs site. - Keep
[env_vars]complete and current — a getting-started guide that misses one variable will block every new hire. - Use the freshness checker on a schedule, not once; it is the step that prevents documentation rot.
- Pick a
[doc_standard]like Diátaxis up front so tutorials, how-tos, reference, and explanation stay cleanly separated. - Review the generated glossary against your real domain terms; the model mines names well but can miss intent behind them.
