plan-mode
Plan Mode
Core rule: no code, no file edits
In plan mode, the agent talks through the problem with Uthman 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. Uthman 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.