| name | brainstorming |
| description | Explore user intent and turn ideas into fully formed designs through collaborative dialogue. Use before creating features, building components, adding functionality, or modifying behavior. Ensures requirements are clear before implementation begins. |
Brainstorming Ideas Into Designs
Overview
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
The Process
IMPORTANT: Ask questions in chat with structured options (lettered/numbered choices). Prefer multiple choice over open-ended when possible — do not invent a non-existent question tool.
Understanding the idea:
- Check out the current project state first (files, docs, recent commits)
- Batch related questions together (2-5 per message), split only when answers have dependencies
- Prefer multiple choice questions when possible, but open-ended is fine too
- Focus on understanding: purpose, constraints, success criteria
Exploring approaches:
- Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why
Presenting the design:
- Once you believe you understand what you're building, present the design
- Break it into sections of 200-300 words
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense
After the Design
Documentation:
- Write the validated design to
docs/plans/YYYY-MM-DD-<topic>-design.md
Implementation (if continuing):
- Ask: "Ready to set up for implementation?"
- Read and follow
writing-plans skill to create detailed implementation plan
Key Principles
- Structured options in chat - Present lettered/numbered choices; avoid vague open prompts when a short option list works
- Batch related questions - Ask related questions together (2-5 per message), split only when answers have dependencies
- Multiple choice preferred - Easier to answer than open-ended when possible
- YAGNI ruthlessly - Remove unnecessary features from all designs
- Explore alternatives - Always propose 2-3 approaches before settling
- Incremental validation - Present design in sections, validate each
- Be flexible - Go back and clarify when something doesn't make sense
