This is the track applied to the situation it was written for: you have just been handed a codebase you did not write, and you want an agent to be genuinely useful in it today rather than next month.
Roughly ninety minutes. Do it in order.
0. Before anything (5 min)#
Clone it. Get the tests running by hand — not with the agent. You need to know what "working" looks like before you let anything change it.
If the tests do not run, that is your first task and you should do it yourself. An agent debugging a build it has never seen, in a repo it has no context for, is the worst possible starting position.
Commit or stash everything. Clean tree.
1. Have it survey, not summarise (15 min)#
Do not ask "explain this codebase". You will get an essay assembled from directory names.
Ask for specific, checkable things:
Answer these, quoting the file and line for each:
- What is the entry point, and what happens in the first 50 lines of it?
- How do I run the tests? How do I run just one test?
- Where does configuration come from, in precedence order?
- What talks to the database, and is there an ORM or raw SQL?
- Which directories are generated or vendored — anything I should never edit by hand?
- What is the largest file, and what is in it?
If you cannot find something, say so rather than guessing.
Every answer is verifiable in seconds. That matters: you are calibrating how much this agent's answers about this codebase are worth, before you rely on them.
2. Find the invariants (20 min)#
This is the part that pays for the whole exercise, and it is the part everybody skips.
Find rules in this codebase that are enforced by convention rather than by the compiler — things that would break at runtime or in production if violated, but compile fine.
Look at: test names containing "invariant", "must" or "never"; comments containing WARNING, IMPORTANT, or "do not"; migration files; anything in a directory named internal, core or domain.
For each, quote the evidence. Mark anything you inferred rather than read.
You will get maybe ten candidates. Two or three will be real, and those two or three are the difference between an agent that helps here and one that quietly breaks things.
Check them yourself. Ask whoever handed you the repo about the ones you cannot verify — that conversation is valuable regardless.
3. Draft the memory file (15 min)#
Now you have material. Have it write the draft:
Write a CLAUDE.md for this repository. Include: what the system is in two sentences, the exact commands to build/test/lint, the invariants we just confirmed, a numbered "how to work here" procedure, and an explicit "do not" list.
Do not include a directory listing or anything derivable from reading three files.
Then edit it yourself. Cut a third. The draft will be too long and too generic in the middle; the parts worth keeping are the commands and the invariants.
Commit it. This file is now the highest-leverage thing in the repo for everyone who follows.
4. Set permissions (10 min)#
From lesson 6, applied here:
- Allow: reads, searches, the test/lint/build commands you verified in step 0
- Allow: writes inside the repo, local git
- Deny: push, deploy, anything touching a real database, anything outside the working tree
Write it into the tool's settings file and commit that too.
5. A real first task (20 min)#
Pick something small and genuinely useful. A good first task has a clear right answer and touches two files at most: a bug with a reproduction, a missing validation, an error message that is wrong.
Run the full sequence:
- Reproduce first. Write the smallest failing test. Show me it failing. Do not fix it yet.
- Check the reproduction is real. Read the test. Does it fail for the reason you expect?
- Then the fix, scoped: Fix it. Only
path/to/file.go. Do not reformat, do not rename. - Review in four passes — decisions, tests, boundaries, scope creep.
If step 1 does not reproduce, stop and find out why. That is information about the codebase and it is worth more than the fix.
6. Write down what surprised you (5 min)#
Whatever went wrong in step 5 — it did not know the test command, it edited a generated file, it assumed the wrong error type — goes into the memory file now, while you remember it.
This is how the file gets good. Not by being written well the first time, but by absorbing one correction per task for a month.
What you have after ninety minutes#
- A verified understanding of how the repo builds and tests
- Two or three invariants that were previously only in someone's head, now written down
- A memory file that makes every future session start ahead
- A permission policy that is safe without being annoying
- One shipped change, reviewed properly
- The beginning of a habit
That last one is the point. The setup is not a one-time cost you pay to unlock the tool — it is the tool. Everything else in this track is about keeping it accurate.
Where to go from here#
This track was the foundation. The paid material goes deeper on each piece:
- Repo configuration — skills, slash commands, hooks, and multi-agent setups, in depth
- Spec-driven delivery — the staged pipeline from request to reviewed PR
- Reviewing agent code — the eleven single-purpose review passes and when each is worth running
If the free track was useful and you want the version with the templates already written, that is what the packs are.