What is plan mode
Imagine it this way: You hire an excellent builder. Before they start knocking down walls, you ask for the blueprint. They draw it, you review it, make adjustments, and only then do they begin. Plan mode is the blueprint before construction.
In Claude Code's normal mode, you ask for something and it gets to work: reading files, editing code, running commands. It works well for simple tasks. But when a task is complex, this is like building without a blueprint. The plan mode changes this behavior: instead of acting, Claude first thinks and proposes what you intend to do.
To activate, just press Shift+Tab before sending your message, or include the word "plan" in the prompt. Claude will analyze the codebase, consider the implications, and present a structured plan with the steps it intends to take. You read it, adjust it if needed, and only then authorize execution.
In one sentence: plan mode = Claude shows you what it's going to do before doing it; you decide whether to proceed.
When to use (and when not to)
Imagine it this way: you don’t make a blueprint to change a light bulb. But you do make one to remodel the kitchen. The criteria are the same: complexity and risk.
Plan mode shines when the task involves multiple files, architectural decisions, or when a mistake is costly to reverse. For “add a console.log here,” planning doesn’t make sense. For “refactor the authentication system to use OAuth,” planning can save hours.
The practical rule: if the task touches more than 3 files or you’re unsure of the approach, use plan mode. If it’s a small, reversible change, go straight ahead. You’ll calibrate that intuition over time.
Use plan mode
- - New Feature Across Multiple Files
- - Refactoring that changes interfaces
- - A bug you don't know where to find
- - Dependency Migrations
Go straight to it (no plan)
- - Fixing a Typo or String
- - Add a log or comment
- - Change in a Single Isolated File
- - A task where you already know the way
In one sentence: Use plan mode for complex and risky tasks; direct execution for simple and reversible ones.
Anatomy of a plan
Imagine it this way: A good cake recipe has ingredients, numbered steps, and baking time. A good plan has the same structure: what to do, in what order, and what to check.
A good Claude Code plan has four parts: (1) objective clear in one sentence, (2) list of files that will be touched, (3) ordered steps what will be done in each, and (4) risks or points of attention. If any of these parts are missing, ask Claude to fill them in before approving.
The quality of the plan depends directly on the quality of your request. A vague prompt produces a vague plan. The more context you provide (which patterns to follow, which files to inspect, what not to change), the more precise the plan will be.
In one sentence: A plan needs an objective, files, steps, and risks; if any are missing, ask before approving.
Approval flow — reviewing and adjusting
Imagine it this way: the architect delivers the blueprint. You don't sign off with your eyes closed. You look it over, ask "what if it rains?", they revise it, and you sign the revised version.
When Claude presents the plan, you have three options: approve and it runs, reject and start over, or refine asking for specific adjustments. The third option is the most powerful: "good plan, but change the approach in step 3" or "add unit tests to the plan".
The approval flow is your checkpoint. It's where you apply human judgment: Does the plan make sense for the project? Does it follow existing standards? Does it touch only what it needs to? If any answer is "no," refine it before approving.
What do you do when the plan is 90% good?
In one sentence: the approval flow is your quality checkpoint; refining is almost always better than approving blindly.
Iterating on the plan before executing
Imagine it this way: A writer reviews a draft 3 times before publishing. Each review costs minutes; a bad publication costs hours. Plans work the same way: each iteration on the plan is cheap, while fixing things after execution is expensive.
The most powerful plan mode technique is iterate on the plan multiple times before execution. You don’t need to approve the first draft. Ask Claude: "refine step 2, consider that we already have auth middleware," or "change the order, run the tests first." Each round costs few tokens; fixing incorrect code later costs much more.
Treat the plan as a living document. The first version is rarely the best. Two or three refinement rounds are usually the sweet spot: they capture the nuances without spending too much time planning.
Practical tip
Use specific questions during iteration: "what if the user isn't authenticated?", "how does this affect component X?", "add error handling to step 4". Generic questions like "improve the plan" produce generic answers.
In one sentence: Iterating on the plan is cheap; fixing things after execution is expensive. Refine it 2–3 times before approving.
Common anti-patterns
Three mistakes almost everyone makes at the beginning:
Plan mode anti-patterns
- Rubber-stamp approval: approving without reading. The plan looks long, so you click "go" without checking it. The result: Claude does something you didn’t want, and you spend more time reverting it.
- Over-planning: overplanning, iterating 10 times on the plan without ever executing it. At some point, it's better to execute and fix things than to keep refining the plan indefinitely.
- Plan drift: approving the plan and then, in the next prompt, giving instructions that contradict it. Claude gets confused about what was planned and what you’re asking for now.
Antes de aprovar o plano, cheque: [ ] Li todos os passos (nao so o titulo) [ ] O plano lista os arquivos que serao tocados [ ] Nenhum passo toca algo que nao deveria [ ] Riscos estao identificados [ ] 2-3 rounds de refinamento ja foram feitos Se 3+ falharam, refine antes de aprovar.
In one sentence: don't approve without reading, don't plan without stopping, and don't contradict the plan after approving it.
Module Summary
Next module:
2.2 — Plans That Work: how to create effective plans for features, refactors, and bug fixes.