| Plan mode | Direct execution |
|---|---|
| Large-scale changes | Well-scoped single change |
| Multiple valid approaches | The approach is obvious |
| Architectural decisions (e.g. microservice restructuring) | A single-file bug fix with a clear stack trace |
| Multi-file modification (a migration touching 45+ files) | Adding one validation conditional |
Plan mode's actual value is safe exploration and design before committing to changes, which prevents costly rework — discovering a wrong assumption on file 40 of a 45-file migration is far more expensive than discovering it during an upfront planning pass. The combined pattern most real work actually uses: plan mode for investigation, then direct execution for the planned implementation — not a single either/or choice applied to the whole task.
The discriminator: complexity and reversibility. If discovering something late in the process would force real rework, plan first. Two traps worth naming: "start direct and switch to plan mode if it gets complicated" doesn't hold up when the complexity was already stated in the requirements — it wasn't a surprise, so deferring the planning step doesn't buy anything except a false start. And "let the implementation reveal the natural boundaries" risks exactly the late-discovery rework plan mode exists to prevent.
Any "no" along the top three questions routes to direct execution — it takes all three "yes" answers in sequence to land on plan mode, not just one.
Cross-module link: this mirrors Module 1's
stop_reasondiscriminator — explicit signals beat inference there too. Just as a model shouldn't infer loop completion from a text block's presence, a team shouldn't infer "this will probably stay simple" when the requirements already stated otherwise. In both cases, the explicit signal that's actually available (stop_reason; a requirements document stating scope) is what should decide, not a plausible-sounding shortcut.