Plan mode, enforced

Every session starts in plan mode. Nothing is pressed to get there, and nothing can be edited until a plan is approved.

One line in the user settings does it: "permissions": {"defaultMode": "plan"}. In plan mode Claude reads, searches and asks, but every write and command that changes the machine needs an approved plan first. Headless runs inherit the same default, so a script that needs to edit says so with its own --permission-mode.

Anthropic's guide treats plan mode as something you switch into for bigger work. Here it is the floor, and the next nine stages decide when it ends.

Before Claude plans anything, a hook puts the interview method into its context.

• When. Claude Code runs the hook on every prompt and hands it a JSON payload. The hook reads one field, permission_mode, and does nothing unless it says "plan".
• Once. The full method goes out once per session. The hook claims the send by creating a directory named after the session id. Creating a directory either succeeds or fails, with no moment where two prompts both believe they won. Later prompts get a four-line reminder.
• Again for a second build. Every plan exit writes a heartbeat file. A heartbeat newer than the session's marker re-arms the full send, so a second plan in the same window is interviewed properly too.
• Small enough to arrive whole. Past 10,000 characters Claude Code shows Claude a 2 KB preview of a hook's output instead of the output. In September, 138 of 200 planning sessions got only the preview. The block is now held under 9,800 by a test.

Claude sizes the interview to the ask and says which branch it took, so a wrong call costs one word to fix.

A method that interrogates a typo fix gets switched off, so the short branch matters as much as the long one. On this post Claude's first line was: “This is the long branch: at least five things are open, so I'll ask questions before drafting anything.”

Six slots are the floor it checks itself against: who it is for, what it is, what it is not, why it matters, how it runs, and how we will know it is done. They are never put to me as a form. The slot that changes builds most is why, because it is where “I need X” gets tested for whether X matters at all.

Every decision arrives as a box of options. A hook reads the whole box before it is drawn, and refuses one I could not answer well.

• The hook sees everything first. A PreToolUse hook on AskUserQuestion receives the full question set as its input. Answering with permissionDecision: "deny" and a reason stops the box, and Claude rewrites it from the reason.
• Four beats, counted. Each option needs four sentences: what it is, how it differs, what I will see, what I give up. The hook counts sentence endings and never grades the writing.
• Labels say what a thing does. A file name, a code identifier or a command-line flag in a header or label is refused.
• No side panel. An option carrying a preview switches the dialog to a layout that draws labels only and drops every explanation. That was measured in the program itself, so any preview is refused.
• One position. The set is filled to four where real alternatives exist, and exactly one is marked recommended. The public kit's version refuses a set with none, or more than one.

This machine has asked 1,168 question sets, holding 9,764 questions and option descriptions.

A numbered list of what is still open, shown every round. Tensions outrank assumptions, because resolving one usually changes the build.

A tension is an answer that sits badly against another answer, the goal or the code. An assumption is something taken on faith. Round one closed with six open items: three tensions and three assumptions. After round two it was four, and once those answers were in, none.

The rule that matters is the floor: at least two rounds before sealing. A first round returns answers nobody has had time to be surprised by, and round two is spent on what round one opened. Measured across 212 planning sessions in September, the weekly average ran between 1.40 and 3.02 rounds, and 39% of sessions asked exactly once. The floor exists because of those numbers. It is instructed rather than counted, and the seal is the record the gate checks.

Before sealing, Claude restates the whole intent and asks me to break it. This is where the method found a flaw in itself.

Rounds three and four both asked whether “the restatement above” matched what I wanted. In round four I answered: “I never ever see the statement you ask me about every time we get to this point of the workflow. I NEVER see it.”

The build window then ran a real Claude Code session three times in a virtual terminal. It wrote a paragraph, then asked a four-option question. The box drew 23 rows. On a 30-row screen the paragraph's opening line was off the top, with my interface add-ons on and with them off. On a 60-row screen, the control, it was visible. A short terminal panel had been hiding the most important text in the workflow.

The question hook now refuses any question or option that points at reply text, such as “the restatement above”, “listed above” or “in my reply”. A pointer at another option in the same box is allowed, because the box is on screen. Across the 9,764 historical texts it fires on 131, and “the restatement above” alone appears 16 times. In round five the restatement went inside the question itself, and I confirmed it there.

The confirmed intent is written at the top of the plan file and sealed. Then one more question: watch, or walk away?

The Intent section covers the six slots and any risk I accepted by name. DONE is written as evidence the conversation will show: “each printed in the conversation”, then six checks, then a giving-up point. That phrasing matters two stages from now, because the judge can only read the conversation.

The watch-or-walk question goes through the box like every other decision. Watching keeps the build in this window. Walking away arms the handoff.

Claude cannot leave plan mode until a hook has read the plan and found it sealed.

• Where it sits. A PreToolUse hook on ExitPlanMode. Leaving plan mode is a tool call, so a hook can refuse it before the approval prompt is ever drawn.
• Evidence first. If Claude spawned helper agents to map the code and any has not reported, the exit is refused. Each spawn creates a marker that the agent's own stop removes, and a marker over two hours old is treated as dead.
• A seal that means something. The marker counts only on a line of its own, outside fenced or indented code and comments, so a plan that quotes the marker is not sealed by accident. A seal over fewer than 40 words of Intent is refused as hollow.
• My answer, not the plan's. The WATCH or WALK line must match my answer in a box, given after the seal was written, whose question sentence names both choices. The gate reads that answer from the session transcript.
• Fails open, loudly. If the gate cannot read what it needs, it allows the exit and logs that it did not check, so a skipped check never reads as a passed one.

This session's exit was allowed on its first call. The refusal shown comes from the kit's live test, a real headless run given an unsealed plan.

I approve the plan, and a fresh window opens in auto mode with its first prompt already typed: a /goal built from the plan's DONE line.

• Armed per window. The walk answer leaves a record named after the session id. A PostToolUse hook on ExitPlanMode looks only for its own window's record, deletes it before doing anything else, and checks it names the plan just approved. A failure therefore means a normal approval, never a handoff that fires on tomorrow's plan.
• Claude runs the launcher, in view. The hook does not start a window behind Claude's back. It tells Claude that its next and only action is one launcher command, so the launch and its output land in the transcript as proof.
• The condition is built, not typed. The launcher refuses an unsealed plan and pulls the DONE slot, including continuation lines. If DONE points at a Verification section, it pulls that in too, because the judge never sees the plan file. It wraps the result as “Carry out the approved plan at … Done when all of this is shown by output in this conversation: …”, and refuses anything past /goal's 4,000-character limit. This one came to 1,124 characters.
• One line starts everything. The launcher writes a temporary script, so nothing is quoted three levels deep. That script opens a Windows Terminal tab and runs claude --permission-mode auto --model <pinned id> "/goal …". Setting a goal starts a turn immediately with the condition as its instruction, so that one line is both the first instruction and the grader's spec.
• Two kinds of autonomy. Auto mode approves tool calls inside a turn. /goal starts the next turn. Together the build runs to the end without me prompting, and still stops for my read where DONE says to.

The public kit's handoff hook opens the window itself on Windows and prints the exact command on Mac and Linux.

After every turn of the build, a separate model reads the condition and the conversation, and decides whether the work is done.

• What it is. /goal is a session-scoped Stop hook of the prompt kind. When a turn ends, Claude Code sends the condition and the conversation so far to the small fast model. That is Haiku 5.5 on Anthropic's API, at medium effort, read from logged requests on this machine.
• Three verdicts. Not yet met starts another turn, with the judge's reason as guidance. Met clears the goal. Impossible clears it and records why.
• It cannot be talked round. The judge runs no commands and opens no files. A claim of done counts only if the evidence is printed in the transcript. That is why DONE says “each printed in the conversation”.
• Not the builder grading itself. Completion is decided by a different model with a fresh read, rather than the one that wants to be finished.

Both windows counted, against the same build run inside the planning window. The handoff is not a one-for-one win, and the bill shows what it really saves.

• Every request re-reads its whole context. The model keeps nothing between requests, so each one sends the full conversation so far. A window's cost is the sum of its context at every request.
• The planning window is on both sides. Its 80 requests read 11,778,151 tokens, and its last request carried 200,081. That interview happens either way.
• The fresh start is not free. The build window loaded its own 61,536 tokens of system prompt, tools and setup before doing anything, and that base is in every one of its requests. It replaced a 200,081-token context, so each build request carried 138,545 fewer.
• The build, to the point all six checks were met: 379 requests, starting at 61,536 and ending at 404,305 per request, 101,233,215 read. Both windows together: 113,011,366.
• The same build in one window: the same 379 requests, each carrying the 138,545-token interview on top, ending at 542,850 per request. Total: 165,519,921. The handoff read 52,508,555 fewer, 31.7% less on the whole bill.
• The writing is the same either way. Both windows wrote 494,082 tokens of output in total. The whole saving is in re-reading.

Counted from each request's own usage record in the two session logs. The build is measured up to the moment the six checks were met and the go-live question went to me.