| name | brainstorm |
| description | Use before any feature work — explores intent, asks clarifying questions one at a time, produces a design doc. Invoke before writing any code or plan. |
Brainstorm
Turn ideas into fully-formed designs through collaborative dialogue. Start by understanding the current project context, then ask questions one at a time. Once the design is clear, write a spec and transition to /plan.
Do NOT write any code, scaffold anything, or invoke `/plan` until you have presented a design and the user has approved it.
Checklist
Create a task for each item and complete in order:
- Explore project context — read relevant files, check recent SVN history (
svn log -l 5)
- Ask clarifying questions — one at a time, understand purpose / constraints / success criteria
- Propose 2-3 approaches — with trade-offs and a clear recommendation
- Present design — section by section, get user approval on each
- Write design doc — save to
docs/specs/YYYY-MM-DD-<topic>.md, then svn add + svn commit -m "docs: add design spec"
- Spec self-review — scan for placeholders, contradictions, ambiguity
- User reviews spec — ask user to confirm before proceeding
- Transition — invoke
/plan to create the implementation plan
Process
Exploring the idea:
- Check the current project state first (files, relevant sdp, recent SVN history)
- For large requests spanning multiple subsystems, flag it and help the user decompose before diving into details
- Ask one question at a time — prefer multiple-choice when possible
- Focus on: purpose, constraints, success criteria
Proposing approaches:
- Always propose 2-3 options with trade-offs
- Lead with your recommendation and explain why
- Keep options realistic for a C++ game server (no greenfield architectural shifts)
Working in existing codebases:
- Follow existing patterns (CmdParser layer, Logic layer, Manager singleton, sdp definitions)
- Where existing code has problems that affect the work, include targeted improvements — don't propose unrelated refactoring
Writing the design doc:
- Save to
docs/specs/YYYY-MM-DD-<topic>.md
- Cover: modules touched, protocol changes (sdp), data flow, error handling
- After writing:
svn add docs/specs/YYYY-MM-DD-<topic>.md && svn commit -m "docs: add design spec"
- Ask user to review before proceeding: "Spec committed. Please review and let me know if you want changes before I write the implementation plan."
Key Principles
- One question at a time — don't overwhelm
- YAGNI ruthlessly — remove unnecessary features from all designs
- Explore alternatives — always propose 2-3 approaches
- Incremental validation — present design, get approval, then move on
