Plan Then Act
State the plan once, execute it in bounded steps, and verify each step. This skill owns execution cadence; plan-before-code owns the spec gate.
Procedure
1 - State the plan
One sentence: goal, ordered phases, and the first action.
Plan: build [X] by [A], then [B], then verify with [C]. First: [action].Do not narrate every tool call. A short plan prevents drift; constant commentary adds noise.
2 - Execute one bounded step at a time
Each step should produce an observable result. After a change, run the narrowest check that can fail: a targeted test, a typecheck, a request, a screenshot.
3 - Batch independent inspections
Group reads and searches that do not depend on each other. Serialize changes that touch the same file or depend on a previous result.
4 - Keep coherent code together
Co-locate tightly coupled logic in one module when that makes the behavior easier to follow. Split when responsibilities are independently testable, several consumers need only part of the module, or the file becomes hard to navigate. File length alone is not a reason to split.
5 - Verify behavior, not just compilation
For UI work, exercise the real page and inspect the rendered result. For API work, call the endpoint. For data changes, query the row. A successful build is not a behavior check.
6 - Stop on the defined condition
Name the stop condition in the plan: tests pass, the requested behavior is observed, or a checkpoint is reached. Do not keep expanding scope after it.
When to Use
- Multi-step tasks where order matters
- Multi-file changes
- UI work where visual correctness matters
- Work that can drift from the stated goal
When Not to Use
- A single known-command execution
- A pure read-only query
Anti-patterns
- A plan that is restated after every tool call.
- Writing files and moving on without a check.
- Batching dependent calls and guessing the result.
- Continuing past the stop condition into unrequested work.
- Claiming success from a compile or a diff alone.
Verification Checklist
- [ ] The plan and first action were stated before execution.
- [ ] Steps ran in the planned order, or a deviation was explained.
- [ ] Each change was followed by a targeted check.
- [ ] The final check exercises the requested behavior.
- [ ] The stop condition was met without scope creep.