Reading a plan critically — and editing it before you approve

Claude has finished planning. There is a proposal on screen and a short menu under it. You have been waiting several minutes for this and the thing you want most is code, so the first option is the one your eye lands on.

Lesson 4.2 got you into plan mode and stopped exactly here: a plan appears, and edits stay blocked until you approve it — unless bypass permissions are available in the session, where the docs say those blocks are not enforced. This lesson is about the thirty seconds that follow, the cheapest thirty seconds in the whole workflow.

A plan is a document you are responsible for

The proposal was written by the thing about to execute it. That is not a reason to distrust it, but it does mean nobody else has read it. And approving is not simply "go":

Approving a plan exits plan mode and switches the session to the permission mode each approve option describes, so Claude starts editing. — Permission modes

The plan also outlives the approval. The documented implement step is to approve, "then let Claude code, verifying against its plan" (Best practices) — so this is the reference the work gets checked against, during the run and again when you read the diff in Lesson 4.5.

Lesson 2.5 said a spec you commissioned is a document you are responsible for, not one you received. A plan is the harder version: you answered no interview questions to produce it, so you carry no memory of the decisions inside it, and it arrives at the moment your attention is lowest.

The three-point check

The docs carry one quotable standard for what a useful executable specification contains:

The most useful specs are self-contained: they name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step that proves the feature works. — Best practices

Run it as three questions against the text in front of you:

The third carries the most weight, because it is the only one that fails loudly later. The docs name the pattern it prevents — "the trust-then-verify gap", where Claude produces a plausible-looking implementation that doesn't handle edge cases — and prescribe one fix: always provide verification, and if you can't verify it, don't ship it (Best practices). It costs one line of plan text. The docs' own upgrade of "implement a function that validates email addresses" is the model: it names the example cases and ends with run the tests after implementing — named cases, a runnable command, a result somebody can read. Lesson 5.1 takes that validateEmail rewrite apart as a verification pattern; here it is only the shape to look for in a plan's last step. The docs are blunt about the return: time spent making the spec precise pays off more than time spent watching the implementation.

Ctrl+G: edit it, don't argue with it

You do not have to negotiate with the plan. You can open it.

Press Ctrl+G to open the proposed plan in your default text editor and edit it directly before Claude proceeds. — Permission modes

It appears again in the Plan step of the documented "Explore first, then plan, then code" workflow, and it is the same key that opens your prompt in your editor — Ctrl+G, or the readline-native Ctrl+X Ctrl+E (Interactive mode). One key, two places, one idea: edit the text rather than describe the edit.

The docs give the keystroke and its effect and stop there — nothing about what happens after you save. This course will not invent that flow.

The menu is a permission decision

Three options, and two of them approve (Permission modes):

"No, keep planning" is not a failure

It is one of the three documented options, not what you pick when you have failed to produce a good plan. It is also the cheapest: no code exists, edits stay blocked, and the correction lands before there is anything to unpick.

The two correction routes divide cleanly:

• Ctrl+G when you know what the plan should say: a step names the wrong file, or the scope line is missing and you can write it in eight words.
• No, keep planning when you know something is wrong and not what: the approach assumes a migration you were not going to run, or the plan is confident about a subsystem you suspect it never read.

If you leave planning entirely, you can come back: cycle to plan mode again with Shift+Tab, or prefix your next prompt with /plan, as Lesson 4.2 covered.

Approving with a clean window

There is an off-by-default setting that adds a fourth option — at the top of the list — and it is the one that turns everything else here into a hard requirement.

{
  "showClearContextOnPlanAccept": true
}

Turned on, the menu gains a first option — Yes, clear context and … — which approves the plan, clears the conversation context, and starts implementing from the plan alone (Settings reference). Lesson 4.4 quotes that sentence in full and reads it as evidence about what planning costs; here it is a menu item you can press by accident.

Read those last four words twice. The constraint you mentioned in passing, the file you said to leave alone, the correction you typed into chat instead of pressing Ctrl+G — none of it reaches the implementation. That is the trade, and it is why this course teaches Ctrl+G first: you buy a window planning has not already spent, and you pay in everything you never wrote down.

The rest of that option's label names the permission mode the session continues in and shows how much of your context the planning used. Even when you decline it, that number is the honest price of the plan you just produced — the subject of Lesson 4.4.

The plan file outlives the conversation

Plan mode writes plan files to disk, by default under ~/.claude/plans. A project can relocate them; Claude Code resolves the path relative to the project root and keeps the default when the path resolves outside it:

{
  "plansDirectory": "./plans"
}

That file is not housekeeping. It is why a long run does not forget its own plan:

Claude Code re-injects the plan file after each compaction, so the plan survives where conversation history may not. — Large codebases

The compaction table in Context window says it in one line: the plan is re-injected from disk. Lesson 3.2 sorted a window into what reloads itself and what gets summarised away — the plan is on the reloading side, and everything you only said about it is not.

One more thing happens on approval: accepting a plan gives the session a generated title based on the plan, unless you already named it. Lesson 3.5 made the case for naming sessions — a plan-first session names itself.

The last cheap moment

Rewriting a sentence in the plan costs a keystroke. The same correction after implementation costs a diff review, a rework turn, and a window already spent twice on one misunderstanding. The plan is not paperwork standing between you and the work — it is the last point at which changing your mind is free.