# Quick Brainstorm

> Lightweight brainstorm — 5 versions with estimated probabilities + assumption surfacing. Use when: brainstorm this, give me options, what are my options, quick brainstorm, /quick-brainstorm.

- Skill: `exiao/quick-brainstorm` (Agent Skill)
- Install (CLI): `npx skillmds@latest add exiao/quick-brainstorm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/exiao/quick-brainstorm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: exiao (https://skillmd.com/u/exiao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/exiao/quick-brainstorm

---


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