Implement only after reviewing the plan

Learning objective

Transition from a reviewed plan to direct implementation without conflating investigation and modification.

Core idea

A large Claude Code change needs both phases in order: planning to decide what should change, then execution to make that change. A plan can identify dependencies and propose a migration order, but it is not implemented code. Approval ends the planning phase and selects the permissions under which implementation proceeds.

For the architect reviewing the work, two decisions remain distinct. You accept the design, then decide how individual edits and commands are approved. A reviewed plan can be implemented with manual edit approval; accepting its approach does not require bypassing action checks.

See 3.4.2 for entering planning and its enforcement limits, and 3.4.3 for research isolation. This lesson owns the handoff from their findings to reviewed implementation.

How it works

Review the proposal as an implementation contract

Anthropic recommends separating exploration and planning from implementation so Claude does not solve the wrong problem. Before leaving planning, inspect whether the proposal identifies affected files, the intended behavior, and how you can verify it. Ask for changes to the plan when those details do not support the requested outcome.

For a library migration, a useful proposal identifies shared wrappers, groups of callers, and the behavior each group must preserve. If investigation found different retry semantics, the plan should resolve how the replacement retains the expected behavior before implementing a mass import replacement. The review concerns that decision, not just whether a list of files looks comprehensive.

Give Claude verification criteria it can execute. Anthropic’s best-practices guidance emphasizes checks that return evidence, such as test results, a build exit code, or output compared against a fixture. Name the repository’s actual commands in the request rather than asking for an unobservable assurance that the migration “works.” The plan can specify those checks without pretending they have already passed.

Use Ctrl+G at the proposed-plan prompt to open the plan in your default text editor. You can directly clarify the approach before Claude proceeds. If the plan still assumes behavior you have not agreed, choose to keep planning instead of approving implementation merely because the proposal is detailed.

Use the approval choice that matches oversight

The permission-mode documentation describes these plan-prompt choices:

The first option’s label depends on the session. When auto mode is unavailable, it reads Yes, auto-accept edits. If the session started with bypass permissions enabled, the option instead offers switching to bypass permissions with no further prompts. Read the actual option rather than assuming every approval prompt selects the same permission mode.

Approving a plan exits plan mode and switches the session to the mode described by the chosen option. Direct implementation then means Claude applies the accepted approach under those permissions. It is not a configuration value named direct, and it does not imply that every operation is pre-approved.

Anthropic documents both plan approval and Shift+Tab as ways to leave plan mode and begin implementation. Pressing Shift+Tab does not itself approve the plan. This lesson recommends the approval prompt when your workflow requires an explicit record of design review; the recommendation does not change either documented exit.

Preserve the accepted decisions through execution

After acceptance, give Claude a concrete implementation request tied to the plan and its verification criteria. Anthropic’s example asks Claude to implement the planned flow, write the relevant tests, run the suite, and repair failures. The essential property is that execution produces evidence against the accepted behavior instead of creating an unrelated interpretation of the original request.

The transition can preserve or clear planning context. When showClearContextOnPlanAccept is enabled, the approval list gains an option that accepts the plan and clears the planning context. Do not rely on incidental discussion as the only record of a critical constraint. Make the plan itself state the files, interfaces, exclusions, and verification needed by implementation.

Anthropic also describes using a self-contained written specification in a fresh implementation session. The useful principle is the same: the execution phase needs an actionable agreement, not every exploratory read. Context-management mechanisms are treated more broadly in 5.4; here, the accepted plan must carry the decisions execution depends on.

Return to investigation when the design changes

Execution can reveal evidence that invalidates a plan assumption. If replacing the adapter exposes an undocumented caller contract, distinguish a correction within the agreed approach from a choice that changes it. Do not silently select another architecture just because source editing is now enabled.

Re-enter planning with Shift+Tab or prefix the next prompt with /plan when another design decision needs investigation. Explain which finding changed the assumption and ask for a revised proposal; see 1.6.3 for revising plans from intermediate evidence. This repeats the phase boundary for the unresolved choice; it does not require replanning each routine edit.

The source-edit enforcement exception for interactive terminal sessions with bypass permissions available still applies; see 3.4.2. Choosing the planning workflow again should therefore be paired with a session configuration whose blocking behavior meets your review requirement.

Key distinctions and trade-offs

The migration phases map to the workflow as follows:

Plan acceptance versus action approval: Acceptance agrees the implementation approach. The chosen permission mode decides how edits and commands proceed. Manual oversight is compatible with an accepted plan.

Plan completion versus task completion: A completed plan provides a design. A completed migration provides changed source and verification evidence. Remaining in plan mode cannot substitute for implementation.

Implementation adjustment versus design revision: An edit that follows the accepted behavior can remain in execution. A finding that changes the required interface or selected approach belongs back in investigation and review.

Keeping the same conversation can preserve useful reasoning, but also retains discovery history. Clearing context or using a fresh session puts more responsibility on the plan’s completeness. In either case, a vague “continue” is weaker than an implementation request naming the accepted behavior and checks.

Architecture / decision scenario

A developer-productivity team plans a library migration across 48 files. Explore supplies grouped usage findings, and the main session proposes changing the shared adapter before its callers. The architect reviews the plan and finds that the verification section covers successful responses but omits behavior the investigation identified as risky.

The architect selects No, keep planning, asks Claude to add verification of the identified behavior, and uses Ctrl+G to clarify the excluded generated files. This remains a proposal revision. It does not start source modification.

After review, the architect selects Yes, manually approve edits. Claude leaves plan mode and implements the adapter and caller groups, running the named checks and returning their results. Individual approval prompts are expected, because accepting the plan did not select unattended execution.

During one caller-group update, the team discovers a contract that would require a different adapter interface. They prefix the next request with /plan and investigate the changed assumption before accepting a revised approach. The remaining routine replacements continue directly after that review. The task finishes with implemented changes and check evidence, rather than the presence of a polished plan alone.

Common exam traps

• Trying to complete an entire migration while staying in plan mode.
• Treating Shift+Tab out of planning as proof that the plan was reviewed.
• Assuming every approval prompt selects auto mode or bypass permissions.
• Treating plan approval as approval of every subsequent command.
• Losing critical constraints when implementation begins with cleared context.
• Continuing edits through an unresolved architectural change because implementation has started.
• Reporting plan completion as a successfully verified implementation.

What to remember

Review the design, select implementation oversight explicitly, and execute against named verification criteria. Planning and execution are successive phases of one task. If evidence changes the accepted approach, return to investigation and review before modifying source around another unapproved assumption.

Knowledge check

References

• Anthropic, Choose a permission mode
• Anthropic, Best practices for Claude Code
• Anthropic, Common workflows