Monday, a client hands you a repo you have never seen: no docs beyond a README that oversells, the person who wrote it gone, and a bug that needs fixing by Friday. The old way to get oriented was two weeks of reading. The agentic way is a disciplined hour, and because you will do this for every client, every open-source dependency you need to patch, and every legacy system you inherit, it deserves what consultants give their repeatable work: a protocol, not a vibe.
The protocol: survey, interrogate, map, fence
Pass 1: survey. The opening move is a single read-only dispatch that produces a written artifact, not a conversation. Structure, entry points, dependencies, conventions, test reality. One caution from 1.3 applies hard here: exploration is the fastest way to fill a context window with file reads, and the docs recommend delegating exploration so only findings come back. Run the survey as a subagent dispatch (2.5) or at minimum demand a written report and /clear after, keeping the artifact and discarding the reads.
Survey this codebase read-only. Do not modify anything. Use subagents for exploration where useful. Produce survey.md with exactly these sections:
- WHAT IT IS: one paragraph, from code not README. Note where the README disagrees with the code.
- STRUCTURE: the directories that matter and what lives in each. Skip generated and vendored code, note that you skipped it.
- ENTRY POINTS: how execution starts (bins, exported APIs, servers, jobs), each with file path.
- DEPENDENCIES: runtime deps that shape the architecture (frameworks, DB clients, queues), each with one line on its role. Flag anything pinned old or deprecated.
- CONVENTIONS: naming, file organization, error handling, test layout, as actually practiced. Note inconsistencies; they mark eras.
- TESTS: what is tested, what runs them, whether they appear runnable right now.
- CONFIDENCE: what you did not read and are least sure about.
Cite file paths for every claim. If the repo is too large to survey fully, say what you sampled and how you chose.
Pass 2: interrogate. The survey gives you the skeleton; targeted questions put muscle on it, and here your Part 1 instincts do the work. Ask "trace what happens end to end when a request hits X, with file paths", "where does state live and who mutates it", "show me three places that follow the dominant convention and one that violates it". Verify claims by spot-check: pick two of its citations and read them yourself. An agent's confident wrong answer about architecture costs you a week; five minutes of sampling catches most of it. This is 1.4's altitude rule inverted: you are now the one asking for evidence.
Pass 3: map it into CLAUDE.md. A repo with no CLAUDE.md makes every future session in it start from zero. You now know enough to fix that permanently. /init generates a starter CLAUDE.md from the repo; on a codebase you just surveyed, you can do better: have it drafted from your survey artifacts, then cut it to what steers, per 2.2's discipline: verification commands that actually run, the conventions the code really follows, entry points, and the don't-touch zones you found. Keep it short; you learned in 1.3 why every resident token pays rent.
Pass 4: fence the danger. Legacy code has load-bearing weirdness: the function four modules import with different assumptions, the migration half-applied, the "temporary" flag from three years ago. Before anyone (you or an agent) edits, write the danger map: a section in CLAUDE.md or a standalone DANGER.md naming the fragile zones, why they are fragile, and what must not change without a human decision. This is 2.2's don't-touch rule applied with evidence rather than paranoia, and for legacy work it is the highest-leverage artifact per word this course teaches. Hooks (2.6) can enforce the worst zones mechanically.
Where it breaks
The confident wrong map. The agent asserts "requests flow through the middleware chain in src/middleware" and it is true for half the routes, because the other half predate the chain. Surveys average over eras; codebases are stratified. Countermeasures are built into the protocol: demanded citations, the CONFIDENCE section, and your spot-checks. Treat the survey as a hypothesis document, upgraded to a map only where verified.
Reading instead of doing. The opposite failure is the operator who runs archaeology for two days because it feels productive. The protocol is bounded on purpose: survey, a dozen targeted questions, CLAUDE.md, danger map, then start the actual work. Orientation that outlives its usefulness is procrastination with artifacts. The map improves as you edit; it does not need to be complete before you start.
Stale maps. A CLAUDE.md generated in an hour reflects that hour's understanding. Wrong entries are worse than missing ones, because agents obey them confidently. Date the map, and when a session proves an entry wrong, fixing the map is part of the task, not a chore for later.
Lablab-2-12Run the protocol on Fastify
Goal: Produce a verified survey, a CLAUDE.md, and a danger map for a real codebase you have never read.
Prereqs: git, Claude Code. The target is Fastify, the Node web framework: mid-size, actively maintained, readable, and (verified July 2026) shipping no CLAUDE.md of its own. The survey runs unattended; read ahead while it works.
git clone --depth 1 https://github.com/fastify/fastify && cd fastify, then start a session.- Run the survey dispatch from this lesson verbatim. While it works, do nothing else; when
survey.mdlands, read the whole thing. - Spot-check two claims: pick one ENTRY POINTS citation and one CONVENTIONS citation and open the files yourself. Record each as confirmed or refuted in
survey.mdunder a new AUDIT heading. - Interrogate with one trace: "a request arrives at a registered route: trace dispatch from server start to handler response, file paths at each hop." Spot-check one hop yourself.
- Generate the map: have Claude draft a CLAUDE.md from
survey.mdand the traces, per 2.2's rules (verification commands, real conventions, entry points, don't-touch zones). Cut anything that does not steer. Run one fresh/clear-ed session with the new CLAUDE.md and ask a question the map should answer; confirm the answer uses it. - Fence: write
DANGER.mdwith the three areas you would least want an agent editing unsupervised, each with a one-line why grounded in something the survey found.
Verify
survey.mdexists with all seven sections, file-path citations, and your AUDIT heading showing two spot-checks with outcomes.- The CLAUDE.md is under roughly 60 lines, contains a runnable verification command you tested (Fastify's test suite or a subset), and a fresh session demonstrably used it.
DANGER.mdnames three zones with evidence-based reasons, not generic caution.
>Troubleshooting
- The survey balloons past the context window: you skipped the delegation guidance. Re-dispatch demanding subagents for exploration, or survey
lib/andtest/only; a bounded honest survey beats an unbounded truncated one. - Spot-check refutes a claim: good, the protocol worked. Record the refutation, ask Claude to re-derive that section with the contradicting file in hand, and lower your trust in neighboring claims one notch.
- Tests will not run on your machine: note it in TESTS rather than fighting it; "test suite requires X, unverified locally" is honest map data, and knowing the verification story is broken is itself a survey finding.
Knowledge check
Knowledge check
Part 2 is done when your rig is real, not when the lessons are read. The audit: go through each rubric line and produce the evidence live, today, in your practice repo. Re-run the command, re-trigger a hook, re-run the SDK agent. Anything that fails, fix before checking its box.
Blunt version of what an unchecked box means: every part of this rig is load-bearing for Part 3. The harness discipline coming next assumes hooks that actually block, verification commands that actually run, and an SDK agent pattern you can extend, because 3.7 builds evals on it and Track B builds workers on it. Pass this honestly or Part 3 will be built on sand.
Sources
- Common workflows (understand new codebases, delegate research to subagents): https://code.claude.com/docs/en/common-workflows (fetched July 2026)
- Commands reference (/init generates a starter CLAUDE.md, /memory refines it): https://code.claude.com/docs/en/commands (fetched July 2026)
- fastify/fastify, lab target verified live: active maintenance, mid-size readable JS codebase, no CLAUDE.md present: https://github.com/fastify/fastify (fetched July 2026)