Think first, then touch

What it is and why it matters

When you ask for a change, Claude Code usually starts right away: it opens the files, writes, changes things. If it understood you, great. If it didn't, you find out at the end, when it has already touched five files and you have to figure out what it did and how to go back.

Plan mode separates the two moments. First Claude reads the files, thinks it through and writes down what it wants to do. Then, only once you approve, it does it. In between there's you, with a plan to read instead of work to undo.

Why it matters: you can fix a plan in a minute, a wrong change across several files you can't. And by reading plans you also learn how your app is built, file by file, which is worth a lot if you're not a developer by training. Claude Code's official guide recommends exactly this order: explore first, then plan, then write the code.

1. How to turn it on

There are several ways. In the terminal I almost always use the first one.

• In the terminal, with a session open: press Shift+Tab. The modes go round in a circle, so sometimes you need to press it more than once, until “⏸ plan mode on” shows up under the input box. To leave without approving anything, Shift+Tab again.
• On the fly, with one request: type /plan in front of your message. Claude switches to plan mode and starts right away on that request.
• From the start: launch the session with the command below.
• In the desktop app: in the Code tab, open the mode selector next to the send button and pick Plan. There it only applies to the current session.
• Always, in one project: in the project's .claude/settings.json file you set plan as the starting mode, as in the file below.

claude --permission-mode plan

{
  "permissions": {
    "defaultMode": "plan"
  }
}

If settings.json already exists, add only the permissions part and don't delete the rest. It applies to the sessions you open in the terminal in that folder.

What Claude does in plan mode

It reads the files, can run commands to explore the project, thinks it through and writes you the plan. It doesn't change your files until you approve it. If a command isn't read-only, it may ask your permission before running it: read what it wants to do before you say yes.

2. The sentence for short plans

Nobody reads a long plan. If Claude writes you two pages, you end up approving without reading, and then the plan is useless. That's why, in plan mode, I always paste this sentence after my request:

Before you touch anything, give me a short plan: 5 points max, one line each. For each point: which file and what you change. Then write what you will NOT touch. At the end, tell me how I check that it works: a command to run or what I try myself in the app. If during the work you need a file that isn't in the plan, stop and ask me.

Each piece has a reason:

• “5 points max, one line each”: you read it in half a minute. If the work doesn't fit, it's usually two jobs: split them.
• “Which file and what you change”: you see right away where it's going to put its hands. You don't need to understand the code, recognizing the file names is enough.
• “What you will NOT touch”: that's the boundary. If something you care about is missing there, like the login, you notice before.
• “How I check that it works”: a command or a test in the app. Without it, the only sign the work is finished is Claude telling you “done”.
• “Stop and ask me”: the plan becomes a limit too. If halfway through it finds out it needs another file, it asks you instead of expanding on its own.

If you use the three-line template for your requests (what should happen, what must not change, how we check it), they work well together: the template says what you want, this sentence says what the plan should look like.

One limit to know: the sentence is an instruction, not a lock. Claude usually follows it, but once you leave plan mode nothing really stops it from opening another file. That's why on the delicate parts I choose to approve the edits one by one, as I explain below.

3. Reading the plan and saying go

When the plan arrives, I read it looking for three things:

• A file that has nothing to do with it: if you're changing a button and the payments file shows up in the plan, ask why.
• A step that changes “the whole app”: “I'll update all the components”, “I'll reorganize the folders”. Usually you didn't ask for that.
• A missing check: if the end doesn't say how you verify it, have it written.

Fix those and then you tell it go.

The choices when the plan is ready

Claude shows you the plan and asks how to proceed. These are the choices:

• “Yes, and use auto mode”: you approve and it starts in auto mode, meaning it works without asking your permission at every step, with automatic background checks on risky actions. If auto mode isn't available in your session, you'll see “Yes, auto-accept edits” in its place.
• “Yes, manually approve edits”: you approve and you confirm every edit yourself, one by one. That's the one I pick when the plan touches the login, the database or payments.
• “No, keep planning”: you stay in planning and tell it what to change.

With “No, keep planning” I use short sentences, like:

Remove point [number]: [file] must not be touched. Rewrite the plan, still 5 points max.

If you'd rather fix it by hand, press Ctrl+G: the plan opens in your text editor and you edit it directly, before Claude gets going. When you approve, Claude leaves plan mode and starts working. To plan the next thing, you go back in with Shift+Tab or with /plan.

4. When you don't need it

A typo, a piece of text, a color in a single file, a question: just ask. The official guide says so too: the plan costs time, and if you can describe the change in one sentence you can skip it.

Always use it when you touch more than one file, the database, the login or payments, or when you don't know where to start.

Common mistakes

• Approving without reading: if the plan is too long to read, ask for a short one with the sentence, otherwise it doesn't protect you from anything.
• Saying go to a plan with no final check: before approving, have it write down how you verify that it works.
• Using it for every comma: for a typo or a color ask directly, and keep the plan for work across several files.
• Thinking the sentence really locks Claude: it's an instruction, so on the delicate parts pick “Yes, manually approve edits” and look at every edit.
• Believing you're still in plan mode after approving: approving takes you out of it, so for the next job you go back in with Shift+Tab or /plan.

Checklist

• I see “⏸ plan mode on” under the input box
• I pasted the sentence for the short plan
• The plan has 5 points max, with the files
• It says what it won't touch
• There's a final check I know how to do
• On the delicate parts I approve the edits by hand

Frequently asked questions