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.
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
1---2name: brainstorm3description: 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.4---56# Brainstorm78Turn 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`.910<HARD-GATE>11Do NOT write any code, scaffold anything, or invoke `/plan` until you have presented a design and the user has approved it.12</HARD-GATE>1314## Checklist1516Create a task for each item and complete in order:17181. **Explore project context** — read relevant files, check recent SVN history (`svn log -l 5`)192. **Ask clarifying questions** — one at a time, understand purpose / constraints / success criteria203. **Propose 2-3 approaches** — with trade-offs and a clear recommendation214. **Present design** — section by section, get user approval on each225. **Write design doc** — save to `docs/specs/YYYY-MM-DD-<topic>.md`, then `svn add` + `svn commit -m "docs: add design spec"`236. **Spec self-review** — scan for placeholders, contradictions, ambiguity247. **User reviews spec** — ask user to confirm before proceeding258. **Transition** — invoke `/plan` to create the implementation plan2627## Process2829**Exploring the idea:**30- Check the current project state first (files, relevant sdp, recent SVN history)31- For large requests spanning multiple subsystems, flag it and help the user decompose before diving into details32- Ask one question at a time — prefer multiple-choice when possible33- Focus on: purpose, constraints, success criteria3435**Proposing approaches:**36- Always propose 2-3 options with trade-offs37- Lead with your recommendation and explain why38- Keep options realistic for a C++ game server (no greenfield architectural shifts)3940**Working in existing codebases:**41- Follow existing patterns (CmdParser layer, Logic layer, Manager singleton, sdp definitions)42- Where existing code has problems that affect the work, include targeted improvements — don't propose unrelated refactoring4344**Writing the design doc:**45- Save to `docs/specs/YYYY-MM-DD-<topic>.md`46- Cover: modules touched, protocol changes (sdp), data flow, error handling47- After writing: `svn add docs/specs/YYYY-MM-DD-<topic>.md && svn commit -m "docs: add design spec"`48- Ask user to review before proceeding: *"Spec committed. Please review and let me know if you want changes before I write the implementation plan."*4950## Key Principles5152- **One question at a time** — don't overwhelm53- **YAGNI ruthlessly** — remove unnecessary features from all designs54- **Explore alternatives** — always propose 2-3 approaches55- **Incremental validation** — present design, get approval, then move on
aquarius-mu