Plan mode, review & staying in control

Why planning beats correcting

Today's deliverable is a habit, proven on real work: one multi-file task run through the full control loop - plan, edit the plan, execute, review the diff, rewind - plus your standard prompts rewritten to demand proof. The cheapest moment to fix a mistake is before it happens. Plan mode makes Claude read-only: it can explore your files and think, but cannot change anything until you approve a plan. Two minutes reading a plan replaces twenty minutes untangling a wrong execution.

The working rhythm the official guidance teaches: Explore, Plan, Implement, Commit. Claude looks around, proposes, you approve, it executes, and the result gets saved as a checkpoint. You already do a manual version of this from week one - plan mode makes the tool enforce it.

Plan mode in practice

1. Press Shift+Tab until the mode indicator shows plan.
2. Give the real task: "Reorganize brain/ so SOPs are separated from reference docs, and update CLAUDE.md to match."
3. Claude explores and returns a plan. Read every step - this is the entire point.
4. Want to edit it directly? Press Ctrl+G and the plan opens in your editor. Change steps, delete steps, add constraints, save.
5. Approve when right. Claude switches to executing exactly that plan.
6. Vague plans mean your prompt was vague. Refine and replan - still cheaper than a wrong execution.

Power pairing worth knowing: the opusplan model setting uses Opus 5.5 for the planning phase and Sonnet 5 for execution - expensive brain for the thinking, fast hands for the doing. For a plan that has to be right the first time, raise /effort to xhigh for the planning turn and drop it back for execution.

And for bigger work, the interview pattern: in plan mode say "interview me about this project before proposing a plan." Claude asks structured questions, you answer, then have it write the result to a SPEC.md and start a fresh session to implement against the spec. Clean context, sharp target.

Reviewing changes before and after

After execution, review the diff - the before-and-after of every changed file. In VS Code or the Desktop app this is visual: deletions and additions side by side. You do not need to understand code to review most operator work - you are checking that the right files changed in the right direction, and nothing else moved.

• Did it touch only the files the plan named? Unexpected files are the first red flag.
• Skim the actual content changes - do they match the intent you approved?
• Ask Claude to walk you through it: "Summarize every change you just made and why." It is good at explaining its own work.
• Wrong? Double-press Esc and use /rewind to restore code, conversation, or both to the checkpoint before the change.

Verification: make Claude prove it

The number-one practice in the current official guidance, verbatim spirit: always give Claude a way to verify its own work. Do not ask for the task - ask for the task plus the check that proves it happened. Evidence, not assertions.

• "Clean this list, then show me the row count before and after, and 5 sample rows."
• "Draft the report, then list every claim in it next to its source file."
• "Reorganize the folder, then print the new tree and confirm zero files were lost - count them before and after."

There is an escalation ladder above the prompt level - a /goal condition Claude re-checks every turn until it holds, hooks that block a session from ending until checks pass (week three), the bundled /code-review skill where a second Claude reviews the first one's work, and /code-review ultra, a deeper multi-agent review (three free runs on Pro and Max, then usage credits). For now, the prompt-level habit is 90% of the value: every task ships with its proof.

The trust loop

Calibrate trust the same way you would with a new hire: small tasks, verify everything. As verification keeps passing, give bigger tasks and spot-check instead. The loop: small task, verify, expand, repeat. The endpoint of that loop is the automations of week three and four, where verified-many-times workflows run without you watching.

A pattern to grow into once the loop feels natural: Writer and Reviewer as two separate sessions. One session does the work; a fresh session - with none of the first one's assumptions in context - reviews it. It is the cheapest form of the adversarial review you will meet later, and it catches what the writer session cannot see about itself. Since August 2026 sessions can message each other (SendMessage, ListAgents), so the reviewer can hand its findings straight back to the writer instead of you copying them across.

Do this now

Sources and further reading

• Claude Code documentation
• Worktrees - parallel sessions for writer/reviewer work