A plan is not a contract you must accept as written. It is a draft. Because plan mode is read-only, you can go back and forth on the plan as many times as you like before a single file changes.
Read the plan like a reviewer
When Claude proposes a plan, read it the way you would review a colleague's approach. Check a few things:
- Does it touch the right files?
- Is the order sensible, or does step three depend on something in step five?
- Does it include a way to verify the result?
- Did it miss an edge case you know about?
The plan is on screen as plain words, so gaps are easy to spot before they become edits.
Push back and refine
If something is off, say so and stay in plan mode. You are still read-only, so Claude revises the plan without changing code. For example:
Don't touch the auth middleware. Keep that change in the route
handler instead, and add a test for the empty-input case.
Claude folds your feedback into a new plan. Repeat until it matches what you actually want.
Point at specifics
Vague feedback gets vague plans. Be concrete. Name files, point to an existing pattern you want followed, and call out the parts to leave alone. A plan that references real files and prior examples is far easier to trust than one built on guesses.
Approve when it is right
Once the plan reads correctly, approve it. Approving exits plan mode and Claude starts implementing exactly what you both agreed on. The time you spent shaping the plan is time you will not spend undoing edits.
Comments
Be the first to comment.