| name | brainstorming |
| description | Use when the user asks to design, plan, or explore approaches before implementing โ creating features, building components, or adding functionality that would benefit from design exploration first. |
Brainstorming Ideas Into Designs
Help turn ideas into fully formed designs through collaborative dialogue.
When this skill activates, present a design before writing code. The design can be short (a few sentences for simple projects) โ scale it to the complexity of the task. Get the user's approval before proceeding to implementation.
Process
- Explore context โ check files, docs, recent commits
- Ask clarifying questions โ one at a time, prefer multiple choice, understand purpose/constraints/success criteria
- Propose 2-3 approaches โ with trade-offs and your recommendation
- Present design โ scale each section to its complexity, ask after each section if it looks right
- Write spec โ save to
docs/specs/ (create directory if needed) and commit
- User reviews spec โ wait for approval before proceeding
- Transition โ invoke writing-plans skill to create implementation plan
Design Principles
- One question at a time โ don't overwhelm with multiple questions
- YAGNI ruthlessly โ remove unnecessary features
- Design for isolation โ break into units with one clear purpose, well-defined interfaces, testable independently
- Explore alternatives โ always propose 2-3 approaches before settling
- Scope check โ if the request describes multiple independent subsystems, decompose into sub-projects first
Working in Existing Codebases
- Explore the current structure before proposing changes. Follow existing patterns.
- Where existing code has problems that affect the work, include targeted improvements as part of the design.
- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
After Design Approval
Invoke the writing-plans skill to create a detailed implementation plan. Do NOT invoke any other skill โ writing-plans is the next step.