What this prompt does
This prompt uses Gemini's large context window to read an entire [language] codebase and produce onboarding-grade documentation in one pass. It runs a ten-part analysis: architecture overview, request flow for your [key_flows], database schema, dependency graph, API docs, configuration guide, design patterns, technical debt areas, a setup-to-first-PR onboarding guide, and a domain glossary.
The structure works because it covers the questions a new engineer actually asks on day one, in the order they ask them. The [key_flows] variable focuses the request-tracing on the paths that matter — registration, payments, exports — rather than every route. [focus_areas] biases the depth toward business logic or integration points, while [doc_count] caps how many technical-debt items it surfaces so the report stays actionable. Choosing [output_format] like Markdown with Mermaid diagrams gives you something you can drop straight into a repo wiki.
When to use it
- You've inherited an unfamiliar codebase and need an architecture map fast
- You're onboarding new engineers and want a setup-to-first-PR guide written for them
- You need a dependency graph and request flow for
[key_flows]you don't fully understand yet - You want a domain glossary so the team shares vocabulary
- You're scoping a modernization and need
[doc_count]technical-debt areas identified - You want API and configuration documentation generated from the actual code
Example output
Expect a structured document in your chosen [output_format]: an architecture overview with a component diagram, annotated request flows, a schema and relationship diagram, internal and external dependency graphs, endpoint documentation, an environment-variable guide, a design-patterns section, a ranked technical-debt list, an onboarding walkthrough, and a glossary. Security concerns found along the way are flagged inline.
Pro tips
- Make
[key_flows]the flows you genuinely don't understand — that's where the traced request paths pay off most - Use
[focus_areas]to steer depth; "business logic and integration points" keeps the output useful instead of evenly thin - Always verify the security flags and design-pattern claims against the real code before trusting them — the model can pattern-match incorrectly
- Pick
[output_format]to match your destination; Markdown with Mermaid drops cleanly into most repo wikis - Keep
[doc_count]modest so the debt list stays prioritized and actionable rather than overwhelming - If the codebase is huge, run it per top-level module and stitch the docs together rather than forcing everything into one prompt
