Plan mode

Plan mode is the "think before you act" switch built into Claude Code. When it's on, Claude does all the research it wants — reads files, greps the codebase, looks at git history — but doesn't edit anything. Instead, it writes you a step-by-step plan. You read it, push back, refine it, and only then approve the actual work.

Of all the habits in this module, this is the one that scales the best as your tasks get more complex.

Why bother with a plan?

For trivial tasks ("rename this variable"), planning is overkill — just ask. For non-trivial tasks, planning is the difference between a clean change and a sprawling one. Without a plan, Claude tends to:

• Make a reasonable-looking change that misses an edge case.
• Touch more files than necessary.
• Refactor opportunistically when you didn't ask.
• Get partway through, realise something doesn't fit, and improvise.

A plan surfaces all of that as text first, where it's cheap to argue with. The two minutes you spend reading and refining a plan is the cheapest review you'll ever do.

Entering plan mode

Press Shift + Tab to cycle through modes; plan mode is one of them. The status bar at the bottom of Claude Code will say plan mode in clear text. Or, less formally, just ask in your prompt:

Before you touch anything, walk me through how you'd tackle this. I want a step-by-step plan, not a finished change.

Either way, Claude shifts gears. It'll still use Read, Grep, and Glob to look around — those are non-destructive. But it won't Edit or run Bash commands that modify the project. It'll return a plan, then wait.

What a good plan looks like

A well-written plan from Claude usually has:

• A short summary of the goal in its own words. This is your first signal that Claude understood the request.
• The files it intends to touch, with a sentence on what each change does.
• The order of operations. Sometimes the order matters; sometimes Claude is just being thorough.
• Anything it's uncertain about.Questions for you. Assumptions it's making.

How to read a plan critically

A plan looks tidy and confident on the page. That doesn't mean it's right. Here's what to check:

1. Did Claude understand the goal? The summary in its own words should match what you meant.
2. Are the files reasonable? If you expected one file to change and the plan touches eight, ask why.
3. Is there a step that smells off? Anything that mentions deleting, renaming widely, or modifying config — pause on it.
4. Did Claude flag uncertainty?"I'm assuming X" — verify before approving.
5. What's missing? No mention of tests? No mention of a related file you know is affected? Push back.

Refining the plan

When a plan is mostly right but not quite, the conversation continues without leaving plan mode. You can say things like:

Looks good, but skip step 3 (don't add a new utility — there's already a helper in src/utils/format.ts). And merge steps 5 and 6 into one — they're the same change in different files.

Claude updates the plan, you check it again, repeat until you're happy. Only then approve.

Approving the plan

Plan mode ends with a clear approve action — usually a button or an explicit command like "Go ahead and implement this." Once approved, Claude switches back to its normal acting mode and executes the plan it just wrote down. It won't freelance outside the plan; if something unexpected comes up mid-execution, it'll usually stop and ask.

When NOT to use plan mode

Plan mode adds friction. For the right task, it's a great trade. For the wrong task, it's overhead:

• One-line fixes ("change this button text from X to Y").
• Exploration questions ("explain how this works") — there's nothing to plan, just to read.
• Quick experiments you intend to throw away.

Use it when the task touches multiple files, has any chance of being misread, or is hard to roll back. Skip it for trivial work.