What this prompt does
This prompt uses Copilot to generate documentation directly from your existing code so the docs stay honest instead of aspirational. It is parameterized on [language] and [framework], and it points Copilot at [target_files] to produce [doc_format] documentation with parameter descriptions, return types, throws declarations, and usage examples for each public function. Because Copilot drafts from the real implementation, the result tends to describe what the system actually does rather than what someone hoped it would do.
The structure works because it covers the full documentation surface in a single coordinated pass instead of leaving gaps. Beyond per-function docs, it generates endpoint documentation for [api_pattern] routes — including request and response schemas, status codes, auth requirements, and curl examples — plus module-level overview comments for each service class explaining its responsibility and dependencies. It also creates an Architecture Decision Record template and drafts ADRs for [key_decisions] inferred from the code patterns, a CONTRIBUTING section derived from your package.json and config files, and inline explanations for the algorithms in [complex_files]. Drafting each artifact from the code rather than from memory is what keeps the documentation trustworthy for whoever inherits the project.
When to use it
- You inherited or are handing off a codebase that lacks usable documentation.
- You want endpoint docs with request and response schemas plus curl examples generated from real routes.
- You need ADRs that reflect the patterns already in the code, not aspirational ones.
- Your complex algorithms need step-by-step inline explanations for the next maintainer.
- You want a CONTRIBUTING section inferred from your actual setup and config files.
- You want consistent module-level overview comments across all your service classes.
Example output
Expect a mix of artifacts. You get [doc_format] docblocks above public functions, a Markdown API reference for your [api_pattern] routes with schemas and curl snippets, overview comments at the top of each service class, an ADR template with drafted records for the decisions you listed, a CONTRIBUTING.md section, and annotated inline comments through the complex files. The output is meant to be reviewed and committed alongside the code it describes, not dropped in unread, so you stay the editor of record.
Pro tips
- Scope
[target_files]with globs such assrc/services/*.tsso Copilot documents the right layer instead of trying to cover everything. - Match
[doc_format]to your ecosystem (TSDoc, JSDoc, Javadoc) so IDEs and doc generators pick the comments up automatically. - For
[key_decisions], name decisions that are actually visible in the code; ADRs invented from nothing read as fiction and erode trust. - Always review generated
@throwsclauses and examples, since Copilot can occasionally document behavior the code does not actually have. - Point
[complex_files]at genuinely hard algorithms; trivial files do not need step-by-step narration and just add noise. - Regenerate docs when the code changes, because drafting from stale code quietly reintroduces the drift you were trying to remove.
