TopolearnThis sequence is what separates sessions you can walk away from and sessions you have to babysit.
The workflow the Claude Code team recommends has four steps.
1. Explore: in plan mode, ask Claude to read the relevant area and explain it. "read src/auth and explain how sessions are refreshed". No edits yet. 2. Plan: ask for a concrete plan; edit it (Ctrl+G) until it is right. 3. Code: approve the plan and let Claude implement, telling it how to check its work. 4. Commit: have it commit with a clear message and open a PR.
The most important ingredient is the check. Claude stops when the work looks done; give it something that returns pass or fail and the loop closes on its own. Options:
- Tests as targets: "write a failing test that reproduces the bug, then fix the code until it passes". Writing the test first turns a vague goal into an exact one.
- A build or type check exit code, a linter, a script comparing output with an expected file.
- For UI, a screenshot compared with a design.
Ask for evidence rather than claims: the test output, the command it ran. Reviewing evidence is faster than re-running everything yourself.
Prompting that helps:
- Scope it: which file, which scenario, what to avoid ("no new dependencies").
- Point to examples: "follow the pattern in HotDogWidget.php".
- Describe symptoms and where to look, not just "fix the bug".
- Reference files with
@, paste screenshots, or pipe logs in.
Skip the plan for small, clear changes. And remember the failure modes: the unscoped "investigate everything" that fills the context, and plausible code with no verification. If you can't verify it, don't ship it.
Example
# 1. explore (plan mode, no edits)
> read src/billing and explain how invoices are rounded today
# 2. plan
> users report totals off by one cent on multi-currency invoices.
> plan a fix. Include a failing test that reproduces it first.
# 3. code, with the test as the target
> implement the plan: write the failing test, show it failing,
> fix the rounding, run the billing test suite and paste the result
# 4. commit
> commit with a message explaining the root cause and open a PRRemember
- Explore and plan before editing; skip planning only for one-sentence changes
- Give Claude a pass/fail check, ideally a failing test written first
- Ask for evidence (test output) instead of accepting "done"
Watch out for
- Saying "make the tests pass" without guarding against Claude changing the tests instead of the code; say the tests are the specification.