| name | brainstorming |
| description | Explore multiple approaches before committing — read context, surface tradeoffs, then decide. Use when user wants to compare options, design an API, or says 'brainstorm'. |
| group | process |
Brainstorming
Use when the problem has multiple valid solutions and the choice has long-term consequences: API design, data model, architecture, technology selection.
Process
1. Read the context first
Before generating options, read:
- Existing patterns in the codebase — there may already be an established approach to follow.
- Similar features already implemented — don't invent something the codebase already knows how to do.
- Any stated constraints in tickets, comments, or configuration.
2. Generate options (diverge)
Produce at least three meaningfully distinct approaches. For each:
- Name — one noun phrase.
- Summary — two sentences max.
- Main advantage — what it does best.
- Main cost or risk — what you're giving up.
Do not evaluate yet. Generate first. If one option is clearly dominant, still generate alternatives — the exercise surfaces the tradeoffs you'd otherwise miss.
If a key technical assumption is unproven, include a spike option: a throwaway implementation to test the risky assumption before committing to a direction.
3. Apply constraints (filter)
Filter against the project's real constraints:
- Performance requirements
- Team familiarity and maintainability
- Existing patterns and dependencies in the codebase
- Timeline and scope
Remove options that violate hard constraints. Do not remove options just because they're unfamiliar or non-obvious.
4. Recommend (converge)
Pick one option. State:
- Which option you recommend.
- Why it wins against the specific alternatives — not in the abstract.
- What you are explicitly trading away — be honest, not diplomatic.
Present the recommendation. Do not begin implementation until the user agrees.
Anti-patterns
- Generating one real option and two obvious strawmen to make it look like a comparison.
- Recommending the first option you thought of.
- Listing tradeoffs without actually comparing them against each other.
- Skipping the codebase read and inventing patterns from scratch.
- Framing a spike as a commitment — spikes are exploratory, not production code.
