Implementation in Claude Code benefits from the same discipline as manual work on a bug: a minimal signal first, then expanding the scope. For a fix the preferred sequence is - reproduce the bug, save the failing output, change the minimal area, repeat the same signal, run the nearest regression tests, then typecheck, lint and build as needed, check the diff and only at the end the real behavior. Each step relies on the previous rather than jumping to the finish.
The key move is not to ask "run everything" right away if the suite takes an hour. First you take a focused signal: one test reproducing the problem, which after the fix should go green. Only after confirming the target behavior is fixed do you expand the check to neighboring tests and the full run. The reverse order - running the whole suite on every step - wastes time and blurs the signal: it is unclear what exactly got fixed and what broke along the way.
Checking the diff is a separate step, and you should ask not for praise but for a self-check against the contract. The /diff command shows the changes, after which the agent is asked to compare the diff with the task's original boundaries: find extra changes, uncovered branches, changes in public behavior and assertions that pass even when the old bug is restored. The last is especially important - a test green even on broken code proves nothing, and such a diff must be caught before, not after, the merge.
Review tools differ in depth and cost, and it is worth telling them apart. /code-review checks the current diff or a PR you pass for correctness bugs and cleanups, and the depth is set by the mode - from low to max; /review is its alias, not a lighter command. The ultra mode is a cloud multi-agent review with separate availability conditions. The --fix flag applies the findings and therefore changes the code, needing a repeated review, and --comment posts comments. Separately there is /security-review - a focused security review of a diff.
It helps to gather the review commands into a table once, to choose the tool for the task rather than always running the heaviest. Below is a map: from a quick single-pass to a cloud multi-agent and a security review. You return to it when deciding whether you need a quick look at a PR, a deep analysis or a security check - and remembering that a review by the same model is not independent evidence.
| Command | What it does |
|---|---|
| /code-review [low..max] | Review a diff/PR, depth set by the mode |
| /review | Alias of /code-review, not a separate command |
| /code-review --fix | Applies findings - changes code, needs a re-review |
| /code-review ultra | A cloud multi-agent review (separate availability) |
| /security-review | A focused security review of a diff |
It is exactly this limitation to keep in mind: a review by the same model is useful for finding omissions but does not replace a test, a static analyzer and a person responsible for the merge. The model that wrote the code and the model reviewing it share the same blind spots. So a review is another layer of attention, not a final stamp: the evidence remains a passed test and observation of real behavior, not the agent agreeing with itself.
Product observation is closed by the /run and /verify commands. /run launches the app and tries to see the change in action, and /verify confirms a specific change through building, running and observation. If Claude does not know how to run the project from a clean state, a project-skill generator creates a skill with setup and observation steps. The criterion is framed concretely: which scenario to pass, what should change exactly once, which console errors are unacceptable.
The loop is closed by a structured report instead of general phrases. A good summary names the root cause, the changed files and the purpose of each change, the commands in run order with exit codes, what was checked through the real app, what could not be checked, and the risks with recommended human review. The typical implementation failure is accepting a green test on unverified behavior or "running everything" instead of a focused signal; the right move is a minimal signal, a diff check against the contract and product observation.
# Product observation with a concrete criterion
/verify Open checkout, add two items, update the quantity of one and confirm
that subtotal and total change exactly once, with no duplicate network request.
Save the observations and console errors.