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.

Jump to install

Repository: exiao/pm-skills
Last source activity: July 24, 2026 at 02:42
Detected SKILL.md language: English
Stars: 9
Forks: 3

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/exiao/pm-skills --skill quick-brainstorm

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

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.