What this prompt does
This prompt casts the model as a senior engineer onboarding to an unfamiliar codebase. You paste the file tree and a few key files of a [language] [project_type] into [repo_snapshot], and it returns five concrete artifacts: a three-line project purpose, the entry points, an ASCII data-flow diagram, the top five risky or confusing areas, and a 30-minute reading plan for a new joiner.
The structure works because it forces compression and specificity. A three-line purpose strips away marketing language; naming real entry points (binaries, web routes, jobs) tells you where execution actually begins; and the risk list surfaces where the bodies are buried before you waste time wandering. The [language] and [project_type] variables tune the model's expectations — it knows the conventions of a FastAPI service differ from a Rails app — while [repo_snapshot] is the raw material everything else is grounded in.
The instruction to be concrete and cite file paths is what keeps the output anchored rather than generic. Instead of describing what a codebase like yours might look like, it points at the actual router, the actual job definitions, and the actual modules in your snapshot. The 30-minute reading plan is ordered, not a flat list, so a new joiner reads the files that build understanding fastest first. That ordering, combined with the named risk areas, is the difference between productive onboarding and hours lost wandering an unfamiliar tree.
When to use it
- You inherited a repo nobody on hand can explain and need to ship in it soon.
- You are evaluating a client or open-source project before committing to work.
- You want a fast mental model of execution flow without reading every file.
- A teammate is onboarding and needs a focused 30-minute reading path.
- You suspect risky areas and want them named before you touch anything.
- You are reviewing an acquisition or audit target's code at a high level.
Example output
Expect a tight five-section report: a three-line purpose, a bulleted list of entry points with file paths, an ASCII diagram tracing data from request or trigger through to storage or response, a ranked list of five risk areas each citing a file, and a numbered 30-minute reading plan. It cites paths from your [repo_snapshot] rather than speaking in generalities, and it skips filler.
Pro tips
- Paste a real file tree plus the genuinely load-bearing files into
[repo_snapshot]; a thin snapshot yields a thin analysis. - Set
[language]and[project_type]accurately so the model applies the right framework conventions. - Include config, routing, and entry-point files in the snapshot, since those anchor the diagram and entry-point section.
- If the diagram looks generic, the snapshot lacked the wiring files; add the router or job-scheduler code and rerun.
- Treat the risk list as hypotheses to verify in the code, not gospel.
- For very large repos, run it per-module rather than dumping the whole tree, which dilutes the analysis.
