Codebase Onboarding Tour

Turn an unfamiliar repo into a guided tour: architecture map, the money path traced end to end, conventions inferred, and safe first tasks.

Give me a guided tour of this codebase. I'm [NEW TO THE TEAM / EVALUATING THIS PROJECT / INHERITING THIS CODE], and my first real task will be: [THE TASK, e.g. "add a field to the billing flow", or "unknown, general orientation"].

[IF AGENT: explore the repo yourself, start with the manifest, entry points, and folder structure. IF CHAT: I'm pasting the layout and key files:]
"""
[PASTE: file tree, package manifest, main entry point, one representative feature's files]
"""

Build the tour:
1. **What this is**: in 3 sentences from the evidence: what the system does, for whom, and the architectural style (monolith/services, MVC/hexagonal, server-rendered/SPA+API). Cite the files that told you.
2. **The map**: the 5-8 directories that matter, one line each on their role, and explicitly which directories I can IGNORE at first (generated code, legacy corners, vendored deps) with how you can tell.
3. **Trace one real request end to end**: pick the most central user action visible in the code and walk it: entry point → routing → validation → business logic → data layer → response, with file:line at each hop. This one trace teaches more than any abstract diagram; note where the pattern I see here repeats everywhere else.
4. **Conventions inferred from the code**: naming, error handling, how tests are organized, how config/env flows, the DI or state pattern in use. Quote a representative snippet for each so I imitate the house style, not my habits.
5. **The landmines**: anything a newcomer would plausibly break: implicit ordering, global state, migrations discipline, the module everything secretly depends on, code that looks dead but isn't. Mark each [OBSERVED] (you can point to evidence) or [SUSPECTED] (smells that way: verify with the team).
6. **Oriented to MY task**: for my stated first task: which files I'll touch, the existing feature most similar to copy patterns from, and what "done" looks like here (tests to add where the others live, checks to run from the manifest scripts).
7. **Three questions for the team**: the things the code cannot tell me (why X was chosen over Y, deploy rituals, who owns what).

Rules: every claim points at a file, no generic architecture lecture. Where the code contradicts its own README or comments, flag the contradiction; trust the code.

How to use

Codebase Q&A is the single best first use of an agentic tool in a new job. This structures it into the tour a great senior engineer would give. The end-to-end trace (step 3) is the core: one concrete request followed through every layer beats hours of README reading. Run it in Claude Code or Cursor at the repo root; in chat, the file tree plus one representative feature is enough to start.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.