Plan First Review First — Claude Code Guide

Plan first before changes, review first afterward

For complex or risky tasks, you should not immediately ask Claude to edit code. First investigate the current implementation, create a plan, agree on boundaries, make a small diff, verify it, and only then accept the result.

This is especially important for payments, refund operations, databases, authorization, and production configuration.

Explore → Plan example for a refund

1. Find the controller or another entry point.
2. Trace calls to services and the payment client.
3. Check existing tests and the retry scenario.
4. Assess the risk of changing the external API.
5. Create a short plan with the steps in order.
6. Record risks and the conditions under which you should stop.

1. Add idempotency protection to RefundService.
2. Pass the identifier to PaymentClient.
3. Create a regression test for a retry.

Risks: public API change and impact on retry logic.

Implement in small steps

Claude should be given one plan item at a time, with the permitted files limited and a diff required after every step. A sudden increase in the number of files is a signal to stop and review the direction.

git diff --stat
git diff

Verify and Review answer different questions

• Verify checks tests, commands, logs, and expected behavior.
• Review checks scope, extra files, the public contract, and the clarity of the change.
• Green tests are not automatic permission to merge.

When the full process is needed

• an unfamiliar part of the system;
• a change across several files;
• auth, payments, database, or config;
• production risk or unclear scope;
• refactoring or compatibility with an external API.