| name | brainstorming |
| description | Use BEFORE any creative work — creating features, building components, adding functionality. Explores user intent, requirements, and design before implementation. Hard-gated: no code until user approves the spec. |
Brainstorming Ideas Into Designs
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Do NOT write any code, scaffold any project, or take any implementation action until you have
presented a design and the user has explicitly approved it. This applies to EVERY project
regardless of perceived simplicity.
Checklist (Complete in Order)
- Explore project context — check files, docs, recent commits
- Offer visual companion (if visual questions ahead) — own message, not combined
- Ask clarifying questions — one at a time: purpose, constraints, success criteria
- Propose 2-3 approaches — with trade-offs and your recommendation
- Present design — scaled to complexity, get approval section by section
- Write design doc — save to
docs/specs/YYYY-MM-DD-<topic>-design.md and commit
- Spec self-review — scan for placeholders, contradictions, ambiguity, scope
- User reviews spec — wait for user approval before proceeding
- Transition — invoke
writing-plans skill to create implementation plan
Key Principles
- One question at a time — never multiple questions in one message
- Multiple choice preferred — easier to answer than open-ended
- YAGNI ruthlessly — remove unnecessary features from all designs
- Explore alternatives — always propose 2-3 approaches before settling
- Incremental validation — present design sections, get approval before moving on
After the Design
- Write spec to
docs/specs/YYYY-MM-DD-<topic>-design.md
- Run spec self-review (check: placeholders? contradictions? scope? ambiguity?)
- Ask user to review and approve spec
- Invoke
writing-plans skill — not any other skill
The terminal state is invoking writing-plans. Do NOT invoke any implementation skill.
Spec Self-Review Checklist
- Any "TBD" or incomplete sections? Fix them.
- Do sections contradict each other? Resolve.
- Is this focused enough for a single plan, or needs decomposition?
- Can any requirement be interpreted two ways? Pick one and make it explicit.
