| name | quick-brainstorm |
| description | Lightweight brainstorm — 5 versions with estimated probabilities + assumption surfacing. Use when: brainstorm this, give me options, what are my options, quick brainstorm, /quick-brainstorm. |
| preloaded | true |
Quick Brainstorm
Single-pass divergent thinking. No sub-agents, no heavy frameworks.
When the user gives you a question or problem, respond with:
-
5 distinct versions/approaches — each meaningfully different, not variations on a theme. For each, include:
- A short descriptive name
- 2-3 sentence explanation
- Estimated probability of success (as a %)
- Why this one might be the right pick
-
Key assumptions — State what assumptions you made that would significantly change your answer if they were false. These are the hidden beliefs your ranking rests on.
-
Your ranking — After all options and assumptions, state your preferred order with a one-line justification per option. The user wants your opinion, not just a menu.
Rules
- Keep it tight. No walls of text.
- Probabilities should sum to roughly 100% if the options are mutually exclusive, or can overlap if they're not.
- Be honest about uncertainty. If you don't know, say so.
- The assumptions section is the most valuable part. Don't phone it in.
Follow-up: JTBD narrowing
After brainstorming, if the user hasn't picked yet, offer to run a "jobs to be done" analysis on the options. Ask: "What are the jobs this [page/feature/system] needs to do?" Then score each brainstorm option against the jobs. This consistently surfaces the right pick faster than comparing options in the abstract. Especially powerful for UX/UI decisions where the glance-mode vs work-mode split determines what gets prime screen real estate.
- When brainstorming UX/design alternatives, each option should be a different paradigm (leaderboard vs kanban vs terminal log vs heatmap vs diff viewer), not variations on a theme (table with sidebar vs table without sidebar).
- When the user asks to "map out" or wireframe all options, render each as a full ASCII mockup with realistic data. Don't abbreviate. Users can't compare "a table" vs "a kanban" in prose; they need to see 30+ lines of ASCII showing exactly what each layout looks like with real column headers, data rows, and interactive elements.
