# Break a big task into steps for Claude

A large request like "build the checkout flow" gives Claude one fuzzy target and many ways to miss it. Split the work into a plan and a sequence of small, checkable steps, and each step has a clear goal you can verify before moving on. In Claude Code, plan mode does this for you: Claude researches the codebase and proposes a plan, you approve it, and only then does it touch any files.

## Why does one big prompt underperform?

When you hand Claude a broad task in a single prompt, three things go wrong at once.

- **The target is ambiguous.** "Add authentication" could mean sessions, OAuth, password reset, rate limiting, or all of them. Claude guesses, and a guess you did not intend is hard to unwind once it has written ten files.
- **You cannot review until the end.** If Claude works straight through to a finished result, the first moment you see a wrong decision is after the wrong code exists. Correcting it then costs more than catching it in a plan.
- **Errors compound.** A small wrong assumption in step one (the database is Postgres, not SQLite) propagates through every later step. By the time you notice, the fix touches everything.

Splitting the work addresses all three. A plan surfaces the assumptions before code exists. Small steps give you a review point after each one. And a wrong assumption shows up at the step where it matters, not five steps later.

## Plan first, then execute

The core move is to separate two phases that a single prompt jams together: deciding *what* to do, and *doing* it.

In phase one, Claude reads the relevant files, names the constraints, and writes an ordered list of steps. You read that list. If a step is wrong or missing, you fix the plan, not the code. In phase two, Claude works through the approved steps, and you review the diff after each.

This is the same discipline a careful engineer uses: write the approach down, get agreement, then build. It pairs naturally with [asking Claude to think first](/guides/ask-claude-to-think-first), so the reasoning behind each step is visible before any code lands. Claude Code has a built-in mode for exactly this.

## What is plan mode in Claude Code?

Plan mode tells Claude to research and propose changes without making them. Claude reads files and runs read-only shell commands to explore, then writes a plan. It does not edit your source while the mode is active.

### How do I enter plan mode?

You can switch into plan mode during a session, for a single prompt, or at startup.

| How | When to use |
|---|---|
| Press `Shift+Tab` to cycle modes | You are mid-session and decide the next task needs a plan |
| Prefix a prompt with `/plan` | You want a plan for just the next request, then back to normal |
| Start with `claude --permission-mode plan` | You know the session begins with exploration |

`Shift+Tab` cycles through the permission modes in order: `default`, then `acceptEdits`, then `plan`. The current mode shows in the status bar at the bottom of the terminal. Press `Shift+Tab` again to leave plan mode without approving anything.

To start a fresh session already in plan mode:

```bash
claude --permission-mode plan
```

### Make plan mode the default for a project

If a repository is large enough that you want every task to start with research, set the default mode in the project settings file at `.claude/settings.json`:

```json
{
  "permissions": {
    "defaultMode": "plan"
  }
}
```

Every session in that project then opens in plan mode. You still approve before any edit happens.

## Write a prompt that produces a good plan

Plan mode decides whether Claude edits. The prompt decides whether the plan is any good. A vague prompt in plan mode produces a vague plan. Give Claude the same things you would give a new engineer: the goal, the constraints, and what to leave alone.

```text
Plan how to add password reset to the existing auth system. Do not write code yet.

Read src/auth/session.ts and src/auth/routes.ts first so the plan matches how the current login flow works.

Constraints:
- Reuse the existing email sender in src/lib/email.ts, do not add a new one
- Reset tokens expire in 30 minutes and are single use
- Do not change the public shape of the session object

Output an ordered list of steps. For each step name the files it touches and what changes. Flag anything you are unsure about before listing the steps.
```

Three things make this prompt work.

- **"Do not write code yet"** reinforces the mode and stops Claude from sketching code inside the plan.
- **Naming files to read** anchors the plan in the real codebase instead of a generic pattern Claude assumes.
- **"Flag anything you are unsure about"** pulls assumptions to the surface where you can correct them. This is the highest-impact line in the prompt.

For more on what to put in the prompt and what to leave out, see [context engineering](/guides/context-engineering).

## Review and approve the plan

When the plan is ready, Claude presents it and asks how to proceed. You choose how much oversight the execution phase gets.

- **Approve and review each edit.** Claude works the steps and pauses for you to approve every file change. Use this for unfamiliar or risky code.
- **Approve and accept edits.** Claude makes the edits without pausing on each one; you review the diff afterward. Use this when you trust the direction.
- **Keep planning.** You give feedback and Claude revises the plan. Use this whenever a step is wrong or missing.

Approving exits plan mode and switches the session into the execution mode the option describes, so Claude starts working. Read the plan before you approve. A plan that lists "update the session object shape" when you said not to change it is a thirty-second fix now and a tangled diff later.The approval prompt looks like an ordinary "continue?" dialog, so it is easy to hit approve on reflex and pick "accept edits", which exits plan mode and lets Claude write every step with no per-edit pause. The whole point of planning was the review, and you just skipped it. Treat that prompt as the one place to read the steps, and choose "review each edit" for anything you do not fully trust.

To edit the proposed plan directly before Claude proceeds, press `Ctrl+G` to open it in your default text editor. Change the steps, save, and Claude follows the edited version.

## How big should each step be?

A good step is small enough to verify in one look and large enough to stand on its own. Aim for steps that each produce something checkable: a passing test, a working endpoint, a rendered component.

| Too big | Right size |
|---|---|
| Build the checkout flow | Add the cart total calculation with a unit test |
| Fix the dashboard | Fix the date filter so it respects the selected timezone |
| Refactor the API | Extract the validation logic from the route handler into one module |

If a step's description needs the word "and" twice, it is probably two steps. Split it. Smaller steps mean smaller diffs, and a small diff is one you can read.

## Track progress across the steps

On multi-step work, Claude Code keeps a task list in the status area of the terminal so you can see what is pending, in progress, and done. Press `Ctrl+T` to toggle the list. The tasks persist across context compaction, which keeps Claude oriented on a long task even after the early conversation is summarised away.An approved plan is not a contract. If a later step reveals the plan was wrong (a file is not where it said, an assumption breaks), do not let Claude grind through the remaining steps anyway. Stop it, drop back into plan mode with what you just learned, and revise before more code piles on the wrong foundation.

You do not have to manage the list by hand. Claude creates and updates it as it works the plan. To see everything or clear it, ask in plain language: "show me all tasks" or "clear the task list".

## When should I skip the plan?

Planning has a cost: an extra round of reading and review before any code. For small, unambiguous changes, that cost is not worth paying.

- **Skip the plan** for a one-line fix, a rename, a typo, or a change where there is one obvious way to do it.
- **Use the plan** when the task touches more than two or three files, when there is more than one reasonable approach, when you are working in code you do not know well, or when getting it wrong is expensive to unwind.

A useful test: if you cannot predict which files Claude will change, you want a plan so you find out before the edits land.

## A short worked example

Suppose you want to add rate limiting to an API. Here is the full loop.

1. Enter plan mode with `Shift+Tab`, then prompt: "Plan how to add per-user rate limiting to the API. Read `src/api/middleware.ts` and `src/lib/redis.ts` first. Limit is 100 requests per minute per user. Flag any assumptions before the steps."
2. Claude reads the two files and returns a plan: add a middleware that reads a counter from Redis, increment per request, return a 429 over the limit, add a test for the limit boundary. It flags one assumption: it expects the user id is already on the request object.
3. You confirm the assumption is correct, and approve with "review each edit".
4. Claude works the steps. You approve each diff. The test step fails once, Claude reads the error and fixes it, and you approve the fix.

The plan caught the user-id assumption before any code depended on it. The per-step review caught the test fix. Neither would have surfaced cleanly from a single "add rate limiting" prompt. Plan mode is one piece of a larger set of [Claude Code workflows](/guides/claude-code-workflows) that turn the tool from autocomplete into a teammate.

## Checklist

Before you hand Claude a large task, run through this.

- Is the task more than two or three files, or is the approach unclear? If yes, plan first.
- Did you enter plan mode (`Shift+Tab`, `/plan`, or `--permission-mode plan`)?
- Does the prompt name the files to read and the constraints to honour?
- Did you ask Claude to flag its assumptions before listing steps?
- Is each step small enough to verify in one look?
- Did you read the plan, and fix it, before approving?
- For the execution phase, did you pick an oversight level that matches the risk?

A planned task costs one extra review up front and saves the larger cost of unwinding code that went the wrong way.