Use the Plan subagent so the implementation strategy lands before any diff does

Claude Code ships with a built-in subagent called Plan whose entire job is to design how a change should be made before any change is made. You hand it a task — “add idempotency keys to the order-create endpoint,” “migrate this service off Redis to DynamoDB” — and it returns a step-by-step implementation plan that names the critical files, the order of operations, and the architectural trade-offs it considered. It has every read tool and no Edit, no Write, no NotebookEdit. It can see everything and change nothing.

Why it matters now. The bigger the task, the more the first draft of a plan costs in context. If the main thread is the one doing the planning, it pays for every speculative read in its own window — and once it has planned and started executing, you're entangled with the plan it chose. Plan exists so the strategy can be assembled cheaply in a side context, returned as a written artifact you can argue with, and only then handed to a coding agent (or to you) for execution. Plan-then-do is older than Claude Code; the subagent just makes it a one-tool-call.

Design a refactor before the rewrite. “Use Plan to design how to split the payments module out of the monolith into its own service. Identify the critical files, the order of changes, and what breaks first.” You get a phased plan back — extract the schema, stand up the new service, dual-write, cutover, decommission — with the actual file paths named. Argue with it in chat. Re-prompt Plan if step three is wrong. Only when the plan reads right do you start cutting.

Scope a fix during an incident. “Use Plan to design the change to add a circuit breaker in front of the upstream-pricing call. Include the rollback path.” Plan reads the call sites, names the wrapper file, sketches the breaker config, and tells you which tests to update. You get a strategy that costs nothing to throw away if the on-call decides to roll back to the last good version instead — far cheaper than letting the main agent half-write the fix before you change your mind.

Sequence a multi-step migration. “Use Plan to design the rollout of the new auth header across the seven services that consume it. Constraint: zero downtime, every service must keep accepting the old header for one release.” Plan returns the order, names the gateway changes, and flags which service deploys first. The output reads like a runbook because that's effectively what it is — a runbook is just a plan that survived contact with production.

The trap to avoid. Plan is not a coding agent and not a critic. It will not write the patch and it will not tell you whether the existing code is good. If you hand it “fix this bug” with a stack trace, you'll get a debugging strategy, not a debugged file. Reach for the engineering:debug skill or the general-purpose agent for execution; reach for engineering:code-review for opinion. Reserve Plan for the question “if we were going to do this, how would we do it?”

Once the plan reads right, paste it as the prompt to the agent or human doing the work. The try-it block shows the shortest version of that hand-off.