Plan mode works best as part of a loop. The steps are Explore, Plan, Implement, Verify. Each step feeds the next, and the loop keeps large tasks from drifting.
Explore
Start by letting Claude read. Point it at the files and patterns that matter. Use @path to pull a specific file into view, and ask questions about how things fit together. In plan mode this stays read-only, so you can roam freely without any risk of an edit.
Plan
Next, ask for a plan. A good plan names the files it will touch, the order of changes, and how it will check the result. This is where you catch wrong assumptions. If the plan targets the wrong module, you fix the direction now, while it costs nothing.
Implement
Once the plan looks right, approve it. That exits plan mode and Claude begins making the changes it described. Small, verifiable steps beat one giant leap, so a plan that breaks work into stages is easier to trust.
Verify
Finally, give Claude a way to check its own work. A test, a lint pass, or a build gives it a signal it can act on:
npm run lint
npm test
When Claude can run a check and see the result, it can fix its own mistakes and loop again without you narrating every step.
Why the loop holds
The strength of the loop is separation. Exploring and planning happen before anything changes. Implementing and verifying happen after you approve. That order means surprises show up on screen as words, not as edits you have to undo.
Comments
Be the first to comment.