| name | brainstorming |
| description | Refine rough ideas into validated design docs through collaborative dialogue. Use when the user says "brainstorm", "help me design", "explore a feature", "let's think about", or has a vague idea that needs structure before coding. |
Brainstorming
Use this skill when the user has a rough idea, wants to explore a feature, or says "let's brainstorm" or "help me design." The goal is to refine an idea into a validated design doc before any code is written.
Purpose
Transform vague ideas into fully-formed designs through collaborative dialogue. This skill ensures alignment on what to build before committing to how to build it.
Prerequisites
- A rough idea or feature request from the user
- Access to the repository root (for bounded context via
01-codebase-research)
Workflow
-
Bounded context check.
Announce what you will read before reading anything. Follow the 01-codebase-research rule. Read only README.md, CLAUDE.md, and one relevant directory listing.
-
Clarify with one question at a time.
Ask questions to understand purpose, constraints, success criteria, and affected components. Only one question per message. Prefer multiple-choice when the answer space is finite. Stop asking when you have enough context to propose approaches.
-
Propose 2-3 approaches with trade-offs.
Present each approach with a name, pros, cons, and a clear recommendation with a one-sentence rationale. Apply YAGNI — remove features not needed for the stated goal.
-
Present design in 200-300 word sections.
After an approach is chosen, present the design incrementally. After each section, ask "Does this look right so far?" and wait for confirmation. Cover: architecture, components, data flow, error handling, testing strategy.
-
Write the design file.
Save the validated design to docs/plans/YYYY-MM-DD-<topic>-design.md using today's date and a kebab-case topic slug.
-
Hand off with artifact path.
Output the exact handoff line referencing the saved file path:
**Next step**: In Cursor Composer, invoke rule 11-writing-plans and provide the path docs/plans/YYYY-MM-DD-<topic>-design.md as context.
Expected Output Format
A Markdown design document saved to docs/plans/ containing:
- Problem statement
- Constraints and scope
- Chosen approach with rationale
- Architecture overview
- Component breakdown
- Data flow description
- Error handling strategy
- Testing strategy
Quality Checklist
