When to Re-plan vs Push Through
The decision framework for when execution produces wrong output — re-plan if the approach is wrong, push through if only the implementation has bugs
advancedWhen execution produces unexpected output, you face a choice. The decision hinges on one question: is the approach wrong, or just the implementation? Wrong approach → re-plan. Buggy implementation → push through.
Decision table
| Situation | Action |
|---|---|
| Plans don’t match your vision | Re-discuss: /gsd:discuss-phase N then re-plan |
| Bugs, but approach is right | Push through: /gsd:quick or /gsd:verify-work |
| Executor left stubs or incomplete work | Push through: /gsd:verify-work creates fix plans |
| Plans have 4+ tasks, context degraded | Re-plan: split into smaller plans |
| Scope grew during execution | Add phase: /gsd:add-phase or /gsd:insert-phase N |
Signs to re-plan
- The approach chosen is fundamentally different from what you discussed in
/gsd:discuss-phase - Plans have 4+ tasks — the executor degrades past 70% context before finishing, producing low-quality last tasks
- You need to change what was built, not just fix bugs — the structure is wrong, not just the details
Re-planning means returning to discuss. Re-run /gsd:discuss-phase N with clearer direction, then re-plan from scratch. The cost is a planning round-trip, not lost execution work.
Signs to push through
- Approach is right; individual tasks have bugs or incomplete edge cases
- A few missing items in
VERIFICATION.mdthat don’t affect the architectural direction /gsd:quickcan fix the issue in under 30 minutes — scope is narrow and well-understood
Pushing through preserves all correctly-completed work. Only the gaps need new plans.
Key commands
$ /gsd:verify-work N$ /gsd:quick$ /gsd:discuss-phase N$ /gsd:plan-phase N --gaps