Rubric
Contents — domains, guide and mocks

Plan mode vs direct execution

CCAR-F 3.412 min read · checked 21 September 2026

Task statementDetermine when to use plan mode vs direct execution

Plan or go direct?

What does the change look like?
  • One-sentence diff, clear scope
    Direct executiontypo, log line, rename
  • Several files, clear design
    Short plan, then executeconfirm the file list first
  • Unsure how to approach it
    Plan modecompare options before editing
  • Unfamiliar code
    Explore, then planread first; decide after
The documentation’s shorthand: if you could describe the diff in one sentence, skip the plan.

What plan mode actually does

Plan mode is one of Claude Code’s permission modes. In it, Claude researches and proposes changes without making them: it reads files, runs shell commands to explore, and writes a plan, but it does not edit your source. Edits stay blocked until you approve the plan. It is a safety boundary as much as a thinking aid — nothing on disk changes while you and Claude agree the approach.

  • Enter it by pressing Shift+Tab until the status bar shows plan mode, by prefixing a single prompt with /plan, or by starting with claude --permission-mode plan.
  • Make it the default for a project’s terminal sessions by setting defaultMode to plan in .claude/settings.json.
  • Leave without approving by pressing Shift+Tab again.
  • Edit the plan yourself by pressing Ctrl+G to open it in your text editor before Claude proceeds.

When the plan is ready, Claude asks how to proceed. You can approve and let Claude continue with fewer prompts (in auto mode, or auto-accepting edits where auto mode isn’t available), approve and review each edit yourself, or say “No, keep planning” and tell Claude what to change. Approving exits plan mode and switches the session to the mode you chose, so Claude starts editing.

Explore, plan, implement, commit

  1. Exploreplan mode: read the relevant code, ask questions
  2. Planfiles to change, approach, risks; edit with Ctrl+G
  3. Implementapprove; Claude edits and runs the tests
  4. Commitdescriptive message, open a PR

“No, keep planning” sends you back to refine the plan before anything is edited

The four-phase workflow from the Claude Code best-practices guide. Plan mode covers the first two phases; the approval is the gate between thinking and editing.

When planning pays for itself

The best-practices guide is direct that plan mode is useful but adds overhead. It names three situations where planning is most useful: when you’re uncertain about the approach, when the change modifies multiple files, and when you’re unfamiliar with the code being modified. It names the opposite too: for a small, clearly scoped fix such as correcting a typo, adding a log line or renaming a variable, ask Claude to do it directly.

Signal in the scenarioLean towardsWhy
Change spans many files or servicesPlan modeAgree the file list and order before edits start
Several valid designs (library A vs B, sync vs async)Plan modeChoose an approach once, instead of discovering it mid-edit
Code nobody on the team knows wellPlan mode (explore first)Reading before deciding avoids solving the wrong problem
Architectural impact, hard to reversePlan modeCheap to change a plan; expensive to unwind edits
Single file, clear stack trace, obvious fixDirectThe plan would restate the fix
Well-specified small change with testsDirectVerification, not planning, is the useful safeguard

What each approach buys you

Plan mode

  • No source edits until you approve
  • Surfaces options and risks before work starts
  • Plan can be edited, and outlasts compaction
  • Costs an extra round of review

Direct execution

  • Fastest path for clear, contained changes
  • Relies on tests and review after the edit
  • Risky when the approach is still uncertain
  • Easy to course-correct with Esc or /rewind

Combining them

The choice is not all-or-nothing. A common pattern is to plan the shape of a change, then execute it directly. For large cross-package work, the monorepo guide recommends planning first because Claude writes the plan to a file and Claude Code re-injects that plan file after each compaction, so the plan survives in a long session where conversation history may not.

Exploration itself can be delegated. When you ask for investigation, Claude can hand it to a subagent so file reads stay out of your main context. Claude Code has built-in read-only subagents for this: Explore, for searching and understanding a codebase, and Plan, which Claude uses during plan mode to gather context before presenting a plan. Both deny Write and Edit. Context isolation is covered in depth in 5.4.

Traps the wrong answers are built from

Tempting but wrongDo this instead
Using plan mode for a one-line, well-understood fixAsk Claude to make the change directly and run a check.
Letting Claude start editing a multi-service change straight awayPlan first so the approach and file list are agreed before edits begin.
Treating the plan as final once approvedSay “No, keep planning” or edit with Ctrl+G until it is right; replan if discoveries change the approach.
Running a large exploration in the main conversationDelegate it to a subagent such as Explore so only findings return.
Planning instead of verifying on small changesFor small edits, a runnable test is the safeguard that matters.

You should now be able to

  • Recognise the signals — scope, uncertainty, unfamiliarity, reversibility — that favour plan mode.
  • Recognise small, well-scoped changes that should go straight to execution.
  • Enter, use and exit plan mode, and approve or refine a plan.
  • Combine planning with direct execution, and delegate exploration to a read-only subagent.
  • Explain why a plan file helps in long sessions that compact.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    A product team needs to move session storage from in-memory to Redis. The change touches the auth service, two API gateways and the test harness, and there is debate about whether to use a cache-aside or write-through design.

    How should the engineer approach this with Claude Code?

    1. AAsk Claude to implement the write-through design directly and fix failures as they appear.
    2. BStart in plan mode, have Claude explore and compare both designs, then approve a plan.
    3. CRun the change file by file in separate sessions so no single session gets too large.
    4. DUse auto mode so Claude can make all the edits without permission prompts.
    Show answer and reasoning
    1. AIncorrect. Committing to one design before exploring the alternatives risks building the wrong thing across several services.
    2. BCorrect. Multiple services and an open design question are exactly the conditions where planning before editing pays for itself.
    3. CIncorrect. Splitting sessions without an agreed approach produces inconsistent decisions across services.
    4. DIncorrect. Auto mode reduces prompts; it doesn’t decide the approach. The issue here is design uncertainty, not prompt fatigue.

  2. Question 2

    A stack trace points to a null dereference on line 88 of invoice_pdf.py. The fix is a guard clause, and the file has a unit test suite.

    What is the most efficient approach?

    1. AEnter plan mode and ask for a full remediation plan before any edit.
    2. BAsk Claude to explore the whole billing module first with a subagent.
    3. CSet plan mode as the project default so every change gets reviewed.
    4. DAsk Claude to add the guard clause directly and run the unit tests.
    Show answer and reasoning
    1. AIncorrect. The approach is already clear; a plan would restate a one-line fix and add a review round for nothing.
    2. BIncorrect. Exploration helps with unfamiliar or ambiguous problems; this one is pinpointed by the stack trace.
    3. CIncorrect. That adds overhead to every small task; the choice should follow the task, not a blanket rule.
    4. DCorrect. A small, clearly scoped fix with a check Claude can run is what direct execution is for.

  3. Question 3

    During plan mode, Claude proposes a plan to split a monolith’s reporting module into a separate service. The engineer agrees with most of it but wants the database migration moved to the end and one endpoint left untouched.

    What should the engineer do?

    1. AApprove the plan and correct the order afterwards during implementation.
    2. BEdit the plan with Ctrl+G or choose “No, keep planning” and explain the changes.
    3. CExit plan mode with Shift+Tab and describe the changes in a fresh prompt.
    4. DRun /clear and start the planning again with a longer prompt.
    Show answer and reasoning
    1. AIncorrect. Approving starts edits in the proposed order; the point of the gate is to fix the plan before that happens.
    2. BCorrect. Both keep Claude in plan mode with the plan revised before any source file is edited.
    3. CIncorrect. Leaving plan mode without approving drops the approval gate; the plan still needs revising first.
    4. DIncorrect. Clearing discards a mostly good plan and all the exploration behind it.

  4. Question 4

    Which statement about plan mode is accurate?

    1. AClaude can read and explore, but can’t edit source until you approve the plan.
    2. BClaude can edit files, but every edit needs a separate confirmation prompt.
    3. CClaude cannot read any files until you have approved its outline of the task.
    4. DPlan mode is only available when Claude Code runs headlessly in CI with -p.
    Show answer and reasoning
    1. ACorrect. That is how the documentation describes plan mode: research and propose, with edits blocked until approval.
    2. BIncorrect. That describes the Manual (default) mode, not plan mode.
    3. CIncorrect. Reading and exploring is the whole purpose of plan mode.
    4. DIncorrect. Plan mode is available interactively via Shift+Tab or /plan, and via --permission-mode plan at startup.

Practise every question in Domain 3 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.