What this prompt does
This is a single instruction that turns Claude Code into a documentation pass over your whole repository. It asks for ten linked artifacts — README, API reference, Architecture Decision Records, CONTRIBUTING, a Mermaid ER diagram of your schema, a config reference, a deployment guide, a troubleshooting FAQ, a changelog, and per-module docs — instead of one generic README. The numbered, explicit list is the whole point: Claude Code already has repo access, so a flat "write docs" prompt wanders, but ten named deliverables force it to actually read routes, migrations, config files, and git log to fill each one.
It works because every section is anchored to something real in the code. ADRs come from "decisions visible in the code," the FAQ from "common issues from code patterns," the schema diagram from your actual migrations, and the changelog from recent git history — so the output describes your system, not a tutorial. The closing rule, "keep docs close to code they document," nudges Claude Code to place files where engineers expect them rather than dumping one giant Markdown blob.
When to use it
- You inherited or built a project that has zero docs and need a credible baseline in one pass.
- You're open-sourcing a repo and need README, CONTRIBUTING, and a changelog before going public.
- You want ADRs reconstructed after the fact for decisions nobody wrote down at the time.
- A new engineer is onboarding next week and you need a config reference plus module docs fast.
- You're prepping a handoff to a client or another team and want a self-contained doc set.
- You need a Mermaid ER diagram for a design review and don't want to hand-draw your schema.
Example output
docs/
├── README.md # overview, setup, usage, architecture
├── CONTRIBUTING.md # branch flow, test + lint commands
├── CHANGELOG.md # grouped from git log since last tag
├── adr/
│ ├── 0001-postgres-over-mysql.md
│ └── 0002-jwt-stateless-auth.md
├── api/payments.md # POST /v1/charges → curl + JSON sample
└── database/schema.md # Mermaid erDiagram: users ||--o{ orders
# database/schema.md excerpt
erDiagram
USERS ||--o{ ORDERS : places
ORDERS ||--|{ ORDER_ITEMS : contains
Pro tips
- Set
[decision_count]low (3-5) and[key_modules]to your genuinely load-bearing modules — over-asking produces filler ADRs for trivial choices nobody debates. - Be exact in
[api_endpoints]: "the routes in routes/api.php" beats "all public endpoints" because it points Claude Code at a file instead of guessing surface area. - Match
[deploy_target]to your real pipeline (e.g. "Docker + GitHub Actions to AWS ECS"); a vague target yields a generic deploy guide you'll rewrite anyway. - Run it on a clean branch and review the ADRs first — reconstructed decisions are where the model is most likely to invent a rationale you never had. Treat them as drafts to correct.
- Pair it with a second pass: after generating, ask Claude Code to add a docs-lint step to CI so the README setup commands actually get tested and don't rot.
