| name | brainstorming |
| description | Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores intent, requirements, and design before implementation. |
Brainstorming Ideas Into Designs
Overview
Turn rough ideas into validated designs through collaborative dialogue before a single line of code is written.
Core principle: Understand what you're building before you build it.
Violating the letter of this process is violating the spirit of this process.
The Iron Law
NO IMPLEMENTATION WITHOUT A VALIDATED DESIGN FIRST
If you haven't clarified requirements and gotten design approval, you cannot write code.
When to Use
Always:
- New feature requests
- Significant refactors
- New projects or modules
- Major behavior changes
- Architecture decisions
Exceptions (ask your human partner):
- Bug fixes with clear reproduction
- Typo corrections
- Dependency updates
- Configuration changes
When NOT to Use
- You already have a detailed design document (use
writing-plans)
- The task is a bug fix with clear reproduction steps (use
systematic-debugging)
- The task is a simple configuration change or file edit
- The user explicitly says "just do it, no discussion needed"
Anti-Shortcut Rules
YOU CANNOT:
- Start coding before design approval — even "just to prototype"
- Assume requirements the user hasn't stated — ask, even if it feels obvious
- Present only one approach — always offer 2-3 with trade-offs
- Skip edge cases — "what happens when this fails?" is always relevant
- Design for scale you don't need — YAGNI unless the user requests otherwise
- Accept vague requirements — "make it better" is not a requirement
- Let your bias override the user's intent — recommend, don't dictate
- Skip the "Risks and Unknowns" section — there are always unknowns
