The Four-Phase Workflow: Explore, Plan, Implement, Commit

The Wrong-Problem Trap

The most expensive mistake in agentic coding is implementing the right solution to the wrong problem. It happens when Claude jumps straight from a vague task description to code, makes assumptions about what the task requires, and produces a working implementation of something that is not quite what was needed. By the time you review the output, there is enough plausible-looking code that correcting it is nearly as much work as starting over.

The solution is separating the exploration phase from the implementation phase. When Claude reads files to understand the codebase before deciding what to build, it makes better decisions about what to build. When exploration and implementation are interleaved, Claude starts coding before fully understanding the context and ends up committed to an approach before it has enough information to choose well.

Plan Mode

Plan mode is Claude Code's mechanism for separating exploration from execution. When plan mode is active, Claude can read files, run read-only commands, and answer questions — but it will not make changes. It can explore freely without accidentally creating half-implemented states.

Toggle plan mode with Shift+Tab from the terminal interface, or via the mode selector. Claude indicates when it is in plan mode. Any attempt to write a file or run a modifying command while in plan mode is blocked.

Plan mode is most valuable when you are uncertain about the approach, when the change touches multiple files, or when you are working in an unfamiliar part of the codebase. For small, well-understood changes — fixing a typo, updating a config value, renaming a variable — plan mode adds overhead without benefit. The rule of thumb: if you could describe the complete diff in one sentence, skip the plan.

Phase 1: Explore

Enter plan mode before saying anything about what you want to build. Start by orienting Claude to the relevant parts of the codebase:

"Read src/auth/ and understand how we handle sessions and login. Also look at how we manage environment variables for secrets."

Claude reads, summarizes what it found, and identifies the relevant files and patterns. This is the foundation for a good plan. Claude now knows the actual structure of the codebase, not just what you described about it.

Phase 2: Plan and Align

After exploration, ask Claude to create a plan:

"I want to add Google OAuth. What files need to change? What's the session flow? Create a plan."

Claude produces a written plan — which files to modify, what the implementation sequence should be, which edge cases to handle, what tests to write. Before Claude writes any code, press Ctrl+G to open the plan in your text editor. You can read it, reorder sections, add constraints, or cut scope. When you save and close, Claude proceeds from the edited plan.

This edit-before-proceed step is where the leverage is. You catch misunderstandings before they become code. You add the constraint you forgot to mention in the prompt. You cut the parts that are out of scope for this iteration.

Phase 3: Implement with Verification

Switch out of plan mode and let Claude implement. But do not leave verification as an afterthought — include it in the implementation prompt:

"Implement the OAuth flow from your plan. Write tests for the callback handler, run the test suite after each major change, and fix any failures before continuing."

The verification instruction makes Claude responsible for confirming its own work. You review the result, not the intermediate states.

Phase 4: Commit and Ship

Once the implementation is complete and verified, Claude can commit and open a pull request:

"Commit with a descriptive message explaining what was added and why. Open a PR against main."

Claude uses git and gh to stage, commit, and create the PR. The commit message should explain the what and the why — not the how, which is visible in the diff.

Three Levels of Verification

The implementation phase includes a verification step, but how rigorous that step needs to be varies by context. There are three escalation levels:

In-prompt verification is the lightest option: ask Claude to run the check in the same prompt and fix any failures. "Run the tests after implementing and fix any failures before finishing." This works for interactive sessions where you are present to redirect if something goes wrong.

The /goal condition is the middle option: set a session-level goal that a separate evaluator re-checks after every turn. Claude keeps working until the goal condition holds. This is for longer unattended sessions where you want continuous automated verification without writing a script — tell Claude "run with /goal: all tests pass" and step away. Unlike a Stop hook, /goal requires no scripting; it runs a model-based evaluator against the stated condition.

Stop hooks are the strictest option: a script that runs when Claude tries to end its turn and blocks the turn from completing if the check fails. This is for CI-style requirements that must not be skipped — tests must pass, build must succeed, lint must be clean. The hook is deterministic; it executes regardless of what Claude decides. Combine Stop hooks with /goal for full automation coverage: /goal keeps Claude working toward the target condition; the Stop hook ensures the final state actually satisfies it.

When to Skip the Plan

The four-phase workflow has overhead. For the right tasks, that overhead is worth paying. For others, it is not.

Skip planning when: the change is small enough to describe in one sentence, you already know which file to edit and exactly what to change, you are working in familiar territory with established patterns, or you are doing exploratory work where you want to see how Claude interprets the problem before constraining it. For these situations, a direct prompt is faster and produces equivalent results.

Apply planning when: the feature touches multiple files, you are uncertain about the right approach, you are unfamiliar with the relevant part of the codebase, or getting it wrong would be expensive to fix. The plan separates the thinking from the doing and catches wrong-direction implementations before they accumulate.