quick-brainstorm

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:

1. 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

2. 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.

3. 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.