After Chapters 1 and 2 you should have a grip on what Claude Code is and how it moves. What this chapter builds is a rhythm you can run the same way every day—the four beats of explore, plan, implement, commit.
The reason a shape is needed is plain. On the days it does not work, the cause is usually a skipped beat. You had it write without reading, you handed it the job without a way to verify, you let it run without stopping points. The symptoms differ, but the place you go back to is the same.
The shape of a day — four beats
Have it read the files that matter and put the current state into words. No writing yet.
Get the steps out in front, and correct them yourself. The one cheap place to fix things.
Let it write and run the check right there. Let the Chapter 1 loop turn all the way round.
Once it passes, set a point you can return to. The next exploration starts here.
The gauge for one turn is "if you cannot recall how you got here, it was too big." Four one-hour turns beat one half-day turn almost every time.
This does not mean doing all four every time. A typo fix needs no plan. What you are judging is which beat you can drop, and the starting position is "do them all."
Before you start, hand over a way to verify
There is one thing to do before you enter the four beats: hand Claude a way to check its own work, up front.
As Chapter 1 showed, what runs underneath is the gather → act → verify loop. It is strong because STEP 3 exists, so it can keep fixing until the tests pass. Turn that over and with no way to verify, the loop stops after one turn—it writes, it is probably right, done. That is a chat tool.
"Get the tests passing" is enough. The failure output becomes the next input, and the loop turns without you watching.
You run it, you report the result, you ask again. You become the bottleneck. You only feel like you delegated.
What you hand over need not be elaborate. One line saying "run this command and you will know if it is right" is enough. And this is safer written into a file than said out loud—a CLAUDE.md at the project root gets reread from disk even across a compaction.
Things worth putting in CLAUDE.md (examples)
- Commands to run after a change: tests / type check / linter
- Do not report "done" while they are still failing
- Places not to touch: generated output, production config, and so on
Write that, and it starts checking itself after every change without you saying "run the tests" each time. It is not that you give fewer instructions, it is that fewer moments need one—that is how a shape pays off (how to write it is Chapter 6). The tasks Chapter 1 put on the "poor fit" side fall down here as well, because there is no way to verify to hand over.
Explore — make it read before it writes
Beat one. There is a single job—have it read the relevant files and explain how things stand right now. Still no writing. Skip this and Claude fills in the parts it did not read by guessing. Plausible code comes back, subtly out of step with how the rest is written, and you notice the gap at review or in production.
Bad exploring: "Fix the authentication"
→ editing starts at once. you never see what it assumed
Good exploring: "Find and read the files involved in authentication.
Explain how login is handled right now,
along with a list of the files involved.
Do not change anything yet."
→ the assumptions land on screen. if they are off, fix them here
The explanation that comes back is for you to read. This is the cheapest place to step in. "That file is not in use any more" costs a sentence, a small fraction of what it costs to find a wrong implementation at review.
Exploration also has a price. Every file it reads lands in the context, so the wider you explore the less room you have later—the Chapter 1 line about getting sluggish and forgetting the early part starts here. Three ways to hold it down.
- Bound the scope—"just the authentication side for now." You need the shape of the whole, not every file in it
- Read huge files in parts—whole-file reads fill you up fast. A line range or a single function is usually enough
- Split off investigations with heavy output—log digging and mass searches go to a subagent. It has its own context and returns only a summary, so the main one does not swell (Chapter 6)
Plan — when plan mode pays, and when it drags
Beat two. Get what changes in what order out on the table before any writing starts. Claude Code has a plan mode for exactly this beat: it investigates, stops at presenting the plan, and goes no further into writing until you approve. How you switch into it varies by version, so check the help in the version you have.
What it really does is move the permission gate from "every edit" to "the entrance to the work". By default a check comes with every tool call; plan mode collects them into one and brings it forward. What you approve stops being "this one line" and becomes "the approach to this piece of work."
It spans several files / there is more than one way to do it / it has to match an existing design / undoing a mistake is painful / you have not settled on the best move either
There is only one thing to do / the steps are already decided / a mistake is undone instantly / reading the plan takes longer than the implementation
Skip the right-hand side without guilt. Plans are not free: they cost time to make, time to read, and context. When one arrives, look at exactly three things. 1. Are the assumptions right (if beat one was off, the whole plan is off with it). 2. Is verification in there (if "get the tests passing" is missing, add it). 3. Are the steps small enough (a plan that does everything in one move leaves you unable to locate the cause when it fails).
For long work, put the plan into a file. A plan that exists only inside the conversation gets crushed into a summary once the session runs long. Have it written out somewhere like PLAN.md and you can reread it after folding the context up, and it doubles as the place to resume from when you step away.
Implement — small steps, fixed as you run
Beat three. Only now does it write. Two principles.
One: run the check after every move. Bundle five changes and then test, and you have given yourself the job of working out which one broke it. Write one, pass one, and the cause is the move you just made. This is for you more than for Claude.
Two: hand over failure output as it is. There is no need to summarize and relay it. STEP 3 is "read the output and go back to STEP 1," so the raw output is the input with the most information in it. Chewing it over for Claude actually removes clues.
One turn while implementing (repeat it in small steps)
[EDIT] rewrite exactly one item from the plan
↓
[RUN] run the tests / the type check
↓
green → on to the next item (or commit)
red → read the output, back to [EDIT]
Three reds in a row in the same place: stop asking for fixes
→ put your hands down and move to diagnosis (Chapter 4)
That last line is a rule of thumb. When the same failure starts repeating, it is usually not "nearly fixed" but a signal that an assumption is wrong.
When the check takes a while—a long build, waiting on CI—you can hand it off instead of sitting there. Claude Code can repeat an instruction at a set interval, and when you leave the interval out, Claude decides for itself when to look again, and stops the loop once it judges the work done. How it works and what it cannot do is in What the /loop command is. Be aware that closing the session stops it.
Commit — you set the stopping points
Beat four. Once the tests pass, commit right there. Not "after I get to a good stopping point"—the moment it passes is the good stopping point.
- It becomes a point you can return to—when the next move fails, you can get back to somewhere that was definitely green
- It keeps the diff readable—half a day of changes cannot be read. A diff nobody can read is effectively unreviewed
- It frees you to cut the conversation—with the work banked, throwing a session away stops being frightening
Letting it write the commit message is fine, but do not approve without looking at the diff. Decide that you are looking not for "what changed" but for "whether something I never meant to change got mixed in," and your eyes stop sliding over it.
Note that committing and pushing are separate decisions. How far to delegate operations that are hard to take back, deployment among them, is Chapter 5.
Folding a session up, and rewinding
A few turns through the four beats and you will always run into the context filling up. When the two symptoms from Chapter 1 show—sluggish responses, the early part forgotten—it is time to fold. There are two ways, compacting and starting fresh, and one thing decides between them.
If what comes next is a continuation, compact—you carry the history over as a summary, and being able to say what to keep is what separates it from the automatic version. If what comes next is a different job, start fresh—if you do not even need the summary, you do not need to pay for making one. Not dragging unrelated work along also gets you better accuracy.
The timing has a shape too. Press it at a break in the work, not by the clock or a percentage—when a turn is done, just before a long stretch begins. Press it mid-flow and details you were about to use get crushed into the summary. The reasoning is in Should you run /compact on a schedule?.
Before folding, get anything you cannot lose into a file. The CLAUDE.md at the project root and the automatic memory are reread from disk, so they survive any number of folds, but decisions that live only in the conversation get thinned out by the summary.
There is another mechanism that changes how you delegate in the first place. Claude Code creates a return point automatically for every prompt, so when things go wrong you can rewind to one. You can choose code only, conversation only, or both, and the one you will use most is "roll the code back, keep the conversation"—the changes are undone while you still remember what was wrong with them, so you can restate it.
What makes it valuable is less the convenience than how it changes the risk you can take. Believing you cannot undo things, you check every single move, and the point of using an agent thins out. Knowing you can undo them, you hand over bigger pieces, and try it, throw it away if it is bad becomes an option.
What rewinds, though, is only "files Claude changed with an edit tool." Files a shell command created or deleted, your own edits, and the state of a database do not come back. It is no substitute for Git, and it assumes you are also committing at the milestones. The line runs like this: work that stays inside file edits, hand over in big pieces. Work that changes state through a shell, commit before you hand it over. The details are in Checkpoints and rewind.
Getting it reviewed — separate the writer from the reader
Code that passes the tests is not necessarily good code. Tests guarantee that nothing is broken, but they say nothing about whether that was the right way to write it.
One principle. Separate the context that wrote it from the context that reads it. Saying "review this" in the same conversation that just finished the implementation tends to get its own judgment rubber-stamped. Seeing every reason behind every choice is a poor state for finding holes. Three concrete moves.
- Read it in a separate session—commit, produce a diff, and hand only the diff to a blank conversation. Have it read by eyes that do not know the history
- Name the angle—not "make it better" but "boundary conditions," "consistency with how the rest is written." A vague request produces vague findings
- Do not take the findings on trust—check them against the real thing. Read first, before you have anything fixed
The third connects to the rest of this chapter. Review is the textbook case of "a task with no way to verify," and with nothing settling right from wrong automatically, Claude will say wide-of-the-mark things in a confident tone. Feed that straight into a fix instruction and you break code that was correct—treat findings as candidates and rule on them one at a time. When you find yourself wanting the same angles every time, that is the signal to turn it into machinery (Chapter 6).
Multiple sessions — how far it pays
Getting on with something else while one side runs a long test—the thought arrives naturally. Claude Code can start several independent sessions in the background and manage them on one screen. The heart of it is isolation: a background session moves into its own working directory before it edits any file. Reads are shared, writes are separated, so two sessions overwriting the same file cannot happen structurally. The details are in Agent view and dispatch.
The tasks are independent of each other / you do not need to watch the middle / judging from the result is enough / one side is a long wait
They depend on the same design decision / the direction has to be reset partway / they include operations you cannot undo / more results than you can actually check
That last item on the right is the constraint that bites hardest. Parallelizing multiplies the total amount of review. Throw three out and three "is that really so?" questions come back; the checking does not get parallelized. The ceiling on how many you can throw is how many results you can verify. The cost goes up too—background does not mean cheap (Chapter 7).
Before you start running things in parallel, revisit your permission settings. Sessions running in the background inherit their permissions from your settings rather than picking them at the moment. The looser your usual setup, the more "loose permissions, nobody watching" sessions you create, one per job. Chapter 5 comes first.
The dull item that causes the most accidents is cleanup. The workspace a background session made goes away with it when you delete the session. "Finished" and "merged in" are different things—commit before you delete.
Summary
- The rhythm of a day is the four beats of explore → plan → implement → commit. When it goes badly, the cause is usually a skipped beat
- Before you start, hand over a way to verify. Without one, the gather → act → verify loop stops after a single turn
- Explore means reading before writing. But every file read costs room, so bound the scope
- Planning is the mechanism that gathers the permission gate at the entrance to the work. It is heavy for a one-move job
- Implement one move at a time with a check after each, and after three failures switch to diagnosis. Commit the moment it passes
- Compact or start fresh comes down to "is the next thing a continuation or a different job?" Just before folding, write things out to a file
- Rewind restores file edits only. Changes made through a shell do not come back, so pair it with commits
- Review in a context separate from the one that wrote it, and treat findings as candidates. The ceiling on parallel work is how much you can verify
Even with a shape, some days you get stuck. Let the next chapter give you an order to work through. Move on to Chapter 4, "Getting Unstuck".