The Explore → Plan → Code → Commit Workflow

1. Why workflow structure matters

Claude Code is capable enough that it is tempting to just describe what you want and let it run. For small tasks — a two-line bug fix, a renamed variable — this works fine. For anything larger, unstructured prompting reliably produces one of two failure modes: either Claude Code produces technically correct code that solves the wrong problem, or it produces plausible-looking code that makes wrong assumptions about the system it is integrating with.

Both failures share a root cause: Claude Code started writing code before it had enough understanding to write the right code. The Explore → Plan → Code → Commit workflow is a structured remedy. It forces a sequence of checkpoints where you, the engineer, can validate that Claude Code is on track before it takes expensive or hard-to-reverse actions.

The workflow is not bureaucratic process for its own sake. Each phase serves a concrete purpose, and skipping any one of them increases the probability of a bad outcome in a predictable way. Understanding why each phase exists is what turns the workflow from a ritual into a principle you can apply flexibly.

2. Phase 1: Explore

The Explore phase is about building shared understanding before either you or Claude Code commits to a plan. It is always read-only — no files are modified, no plans are finalized.

Ask Claude Code to map the relevant territory: which files are involved, what the current behavior is, what the existing patterns are, and what constraints the solution must respect. For a feature addition, this might mean tracing the data flow from the point where the feature will be added back to the database. For a bug fix, it means reading the failing test, the code it tests, and any related modules that might be contributing to the failure.

The goal of exploration is to surface the things you do not know about the task. Even on a codebase you built yourself, Claude Code’s exploration often turns up a dependency or constraint you had forgotten. Better to find it now than to discover it after the implementation is complete.

A good Explore prompt:

Before we write any code, explore the codebase to understand the relevant context for this task: 
adding email notification support to the user invitation flow. 

Map: where invitations are currently created (file and function), how the email module 
works (look for existing email calls to see the pattern), whether there is a template 
system, and any existing tests for the invitation flow. Report back — do not change anything.

The “report back — do not change anything” at the end is important. It prevents the Explore phase from bleeding into the Code phase before you have reviewed the plan.

3. Phase 2: Plan

With exploration complete, the Plan phase produces a concrete, reviewable proposal for what to build. The plan should be specific enough that you can evaluate it without seeing the code — that is the whole point.

Ask Claude Code to write out the plan as numbered steps, each with a specific file, function, or behavior it will affect. A vague plan (“add email sending to the invitation flow”) cannot be evaluated. A specific plan (“add a sendInvitationEmail(userId, inviteeEmail) function to src/notifications/email.ts that uses the existing EmailTemplate class, then call it from the createInvitation() function in src/invitations/service.ts after the database write, passing the new user’s email from the invitation record”) can be.

Read the plan critically. Ask yourself: Is this the right place to add this? Are the existing patterns being followed or is Claude Code inventing something new? Does the plan account for error handling, tests, and edge cases? Are there dependencies on modules or APIs that the plan does not mention?

If the plan is wrong, correct it now: “The notifications should be sent asynchronously via a job queue, not synchronously in the service layer. The job queue is in src/jobs/ — revise the plan to use that pattern.” A corrected plan costs nothing. Correcting the equivalent amount of wrong code costs real time and effort.

4. Phase 3: Code

The Code phase is where Claude Code does the implementation. Your role during this phase is oversight, not keyboarding. You have already reviewed the plan; now you watch the execution and intervene if something goes off track.

One important principle: trust the plan, not the intermediate output. As Claude Code writes code file by file, individual files may look incomplete or slightly inconsistent — that is fine, because implementation often requires temporary inconsistency that gets resolved as later files are written. What you are watching for is deviations from the plan: a different file being modified, an unexpected dependency being introduced, a test being skipped.

If Claude Code deviates from the plan in a way that looks wrong, interrupt it: press Ctrl+C and ask for an explanation. Sometimes the deviation is correct — Claude Code found something during implementation that makes the plan wrong — and the right response is to revise the plan and continue. Sometimes it is a mistake, and the right response is to course-correct immediately rather than letting the implementation diverge further.

In auto-accept mode during the Code phase, Claude Code works faster but you lose visibility into intermediate steps. A useful hybrid: allow file reads and writes automatically, but require approval for bash commands. This way you see the tests run, approve the execution, and read the results — maintaining a feedback loop on the implementation without slowing down every file write.

5. Phase 4: Commit

The Commit phase is not just git commit -m "done". It is a final human review of everything Claude Code did, treated with the same care you would give a pull request from a colleague.

Before committing, read the full diff:

git diff --staged

Look for: changes in files that were not mentioned in the plan (unexpected scope), missing test coverage for new behavior, hardcoded values that should be configuration, commented-out code that was left in by accident, and any patterns that are inconsistent with the rest of the codebase.

Claude Code can write the commit message for you once you have approved the diff:

The diff looks correct. Write a commit message following the conventional commits format 
(feat/fix/refactor prefix) that accurately describes what changed and why.

If the diff reveals problems, do not commit — go back to the Code phase with specific feedback. A few targeted fixes are much cheaper than a revert after the commit lands on main.

After committing, use /clear to start the next session with a clean context. The work is done; carry only the project structure in CLAUDE.md into the next task, not the conversation history from this one.

claude

Before writing any code, explore the relevant context for [your task]. 
Read the relevant files, trace the data flow, and identify existing patterns 
I should follow. List any constraints or dependencies I should know about. 
Do not change anything.

Now write a numbered implementation plan. For each step, specify: which file 
to modify, which function or class to change, and what the change will be. 
Include the test strategy. Do not write code yet.

git diff --staged

Write a commit message in conventional commits format for these changes.