Plan Mode
Use analysis-first workflows to turn ambiguous requests into safe implementation steps.
Plan mode is useful when the work has unknowns, broad impact, or a high cost of being wrong. It should end with a concrete implementation contract, not with open-ended brainstorming.
When To Plan
Use a planning pass when the task touches:
- Routing, authentication, or permissions.
- Shared data models.
- Multiple packages.
- Public content structure.
- Migrations or destructive operations.
- UI flows that need browser verification.
For small, obvious edits, inspect the local context and implement directly.
A Useful Plan
A plan should name:
- The files or modules likely to change.
- The behavior that must stay unchanged.
- The verification commands.
- The unresolved risks.
- The order of work.
Example:
1. Add `en` to locale config and disable fallback for unsupported books.
2. Add English content only for the selected handbook slugs.
3. Filter home, updates, sitemap, and preview APIs by localized availability.
4. Add E2E coverage for `/en` and unsupported English book routes.Execution Handoff
When moving from plan to implementation, keep the plan nearby but let the codebase correct it. If a local pattern contradicts the plan, inspect the pattern before forcing the planned abstraction.
Review Questions
- Did the plan identify the real shared surfaces?
- Did implementation stay within those surfaces?
- Did verification cover the risk that made planning necessary?
- Are unsupported states explicit instead of hidden behind fallback behavior?