01

Treat planning, implementation, and review as separate decisions

Anthropic recommends exploring before coding and providing observable verification. The workflow here applies that idea to a small label fix. Approval of a plan is not approval to deploy, and a passing test does not substitute for reading the patch.

02

Before you start

Complete a read-only inventory and confirm the project’s instructions. Preserve existing changes. Define an allowed file set and a test that would fail on the current form. Do not assume a particular planning-mode button exists in every client.

03

Example: the disappearing email label

Plan: add a visible label linked to the email input, reuse the existing form spacing, and leave submission logic unchanged. Before editing, type an address and observe that the placeholder disappears. Record this as the failing user-visible check, not as a successful label test.

  • Patch boundary: contact markup plus existing form CSS only.
  • Review question: does the label’s for value match the input id?
  • Regression question: is the original submit handler untouched?
04

Work through the task

  1. Ask for a plan listing exact files, intended behavior, checks, and unknowns. Resolve unknown ownership before editing.
  2. Approve the bounded change and require the agent to preserve unrelated work.
  3. Run the known project checks and repeat the browser observation with text entered. Tab through all controls.
  4. Read the diff separately from the completion summary. Ask for a correction if the patch introduces unrelated cleanup or weakens a test.
05

What a useful result looks like

A good result is a small patch plus evidence of the original failure and the corrected behavior. Report checks with their real outcome and environment. A browser-only check should not be described as end-to-end delivery verification.

06

When to stop or change direction

Stop if the plan unexpectedly needs a framework migration, if the baseline test cannot run, or if the agent removes an assertion to make tests pass. Separate an environment failure from a code defect before proceeding.

07

Verify before continuing

  • Did the acceptance check actually fail before the change?
  • Did only approved files change?
  • Does the final report include limitations and the exact remaining untested behavior?

QUESTIONS THIS ANSWERS

Questions this answers

  • How do I plan and review a Claude Code change?
  • What should I do when generated code passes the wrong test?

Found something wrong? Report an error or read the corrections policy.

1 SOURCESEvidence ledger

Sources

  1. 01
    Claude Code best practices ↗

    Anthropic · accessed 4 Sept 2026