Pick one question that crosses the system
A repository summary is easy to produce and hard to trust. It may list folders without explaining where a real behavior happens. Start with one feature instead: for a fictional team application, “How does a member invitation become an accepted membership?”
The deliverable is a short, evidence-backed map you can review before changing anything. This is an investigation method, not a promise that every codebase can be understood in minutes. Monorepos, generated code, missing services, and undocumented integrations can all leave gaps.
Set the boundary before exploring
Open the correct project folder and tell the agent to inspect the current checkout without editing, installing dependencies, starting services, or contacting external systems. Those actions may be useful later, but they deserve a separate decision. Preserve uncommitted work and note the branch or commit used for the investigation.
Repository files can contain customer data or secrets. Limit the requested output to relevant paths, symbols, and sanitized examples. Do not ask the agent to dump environment files or private configuration. Use account and tool restrictions as well as instructions.
Trace the member-invitation flow in this checkout.
Read project guidance and the relevant source and tests.
Do not edit files, install packages, run migrations, or start services.
Identify the UI entry, request handler, authorization, data write,
and any email or background-job side effects.
For each finding, cite the file and symbol that supports it.
Separate verified facts, inferences, and unanswered questions.
End with the three files I should read first.Follow behavior through boundaries
First identify the route or component that submits an invitation. Follow its request into the server handler, then find authorization and validation before the data write. Check whether the handler performs the work directly or enqueues it for a worker.
Read the corresponding tests. A function named validateInvite does not prove that the caller invokes it, and a passing unit test does not prove that the browser can reach the route. Ask the agent to trace the call site and report any missing link.
- Interface: where the action starts, and which request it sends.
- Access: how organization membership and invitation permissions are checked.
- State: where the invitation is stored and how duplicate or expired tokens behave.
- Side effects: what sends email, schedules work, or writes an audit event.
- Tests: which cases exist and which important cases are absent.
Make the handoff useful for the next engineer
A useful result names the files to read, explains the execution order, and records uncertainty beside the relevant finding. Keep source-derived facts separate from runtime observations. If the email worker is not available, say so instead of assuming the delivery path works.
Request a compact change-impact note: if invitation expiry changes, which validation, background cleanup, interface copy, and tests might be affected? This turns the investigation into a starting point for a small, reviewable change rather than a broad rewrite.
Validate only after agreeing on the next step
When a local preview and test account are available, a second task can observe the browser request and compare it with the source map. Authorize that runtime work explicitly. Keep the first investigation intact so new evidence can confirm or correct its assumptions.
Store the agreed map in your team's normal documentation only if you want a persistent artifact. Record the checkout and review date; a map can become stale as routes and permissions change. The final checkpoint is simple: can another engineer use the cited evidence to verify the same explanation?