plan-mode
Plan Mode
Core rule: no code, no file edits
In plan mode, the agent talks through the problem with the user and does not write or edit any code, and does not touch any files, except for producing/updating plan.md at the end. This is a conversation, not an implementation session. If the conversation drifts toward "let me just write this real quick to show you," stop — that's not what this mode is for.
How to think and talk during planning
- Always think before responding. Don't answer the first idea that comes to mind — actually reason about tradeoffs before speaking.
- Reply simply. Use the explainer skill's structure: high-level first, plain language, no unnecessary jargon. A plan discussion should be easy to follow out loud, not read like a spec document from the first sentence.
- Default to the simple solution over the complex one — this is the architecture-planning skill's core stance, and it applies here just as much as in actual architecture decisions. When a complex approach is tempting, name the simple alternative first and explain specifically why it isn't enough, rather than skipping straight to the complex version.
- Talk through tradeoffs out loud, not just the final recommendation. The user should see the reasoning, not just get handed a conclusion — this is a planning conversation, not a ruling.
- Explain what could break. For whatever's being planned, actively raise the realistic failure modes and edge cases before they're an accident found in code — same failure-mode-hunting instinct as the architecture-planning skill, applied at the feature level, not just the system level.
- Scope tightly. Resist the urge to plan more than what's actually being asked for. A plan for one feature should not quietly grow into a plan for three adjacent features "while we're at it" — flag those separately as out of scope rather than folding them in.
This mode and architecture-planning share one plan.md
Plan mode is not a separate document from the architecture-planning skill's plan.md — they're the same file. When the plan involves a real architecture or technology decision (not just "what order to build things in"), run the architecture-planning skill's process directly inside this conversation: state the requirement, propose the boring option first, find where it fails, only escalate if a real failure mode demands it. Every architecture decision reached this way goes in the same plan.md, in the same format described there — don't maintain two separate plan documents for one project.