|
| 1 | +--- |
| 2 | +name: brainstorming |
| 3 | +description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation." |
| 4 | +--- |
| 5 | + |
| 6 | +# Brainstorming Ideas Into Designs |
| 7 | + |
| 8 | +## Overview |
| 9 | + |
| 10 | +Help turn ideas into fully formed designs and specs through natural collaborative dialogue. |
| 11 | + |
| 12 | +Start by understanding the current project context, then ask questions one at a time 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. |
| 13 | + |
| 14 | +## The Process |
| 15 | + |
| 16 | +**Understanding the idea:** |
| 17 | +- Check out the current project state first (files, docs, recent commits) |
| 18 | +- Ask questions one at a time to refine the idea |
| 19 | +- Prefer multiple choice questions when possible, but open-ended is fine too |
| 20 | +- Only one question per message - if a topic needs more exploration, break it into multiple questions |
| 21 | +- Focus on understanding: purpose, constraints, success criteria |
| 22 | + |
| 23 | +**Exploring approaches:** |
| 24 | +- Propose 2-3 different approaches with trade-offs |
| 25 | +- Present options conversationally with your recommendation and reasoning |
| 26 | +- Lead with your recommended option and explain why |
| 27 | + |
| 28 | +**Presenting the design:** |
| 29 | +- Once you believe you understand what you're building, present the design |
| 30 | +- Break it into sections of 200-300 words |
| 31 | +- Ask after each section whether it looks right so far |
| 32 | +- Cover: architecture, components, data flow, error handling, testing |
| 33 | +- Be ready to go back and clarify if something doesn't make sense |
| 34 | + |
| 35 | +## After the Design |
| 36 | + |
| 37 | +**Documentation:** |
| 38 | +- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md` |
| 39 | +- Use elements-of-style:writing-clearly-and-concisely skill if available |
| 40 | +- Commit the design document to git |
| 41 | + |
| 42 | +**Implementation (if continuing):** |
| 43 | +- Ask: "Ready to set up for implementation?" |
| 44 | +- Use superpowers:using-git-worktrees to create isolated workspace |
| 45 | +- Use superpowers:writing-plans to create detailed implementation plan |
| 46 | + |
| 47 | +## Key Principles |
| 48 | + |
| 49 | +- **One question at a time** - Don't overwhelm with multiple questions |
| 50 | +- **Multiple choice preferred** - Easier to answer than open-ended when possible |
| 51 | +- **YAGNI ruthlessly** - Remove unnecessary features from all designs |
| 52 | +- **Explore alternatives** - Always propose 2-3 approaches before settling |
| 53 | +- **Incremental validation** - Present design in sections, validate each |
| 54 | +- **Be flexible** - Go back and clarify when something doesn't make sense |
0 commit comments