10 ways to use the Claude brainstorming skill (2026)

writing-plans

The only skill brainstorming hands off to once the spec is approved.

github

Commit the spec and open the tracking PR so the design lives in the repo.

Decompose an over-scoped 'platform' into sub-projects

Stop a 'build me a platform' request from becoming one giant unbuildable spec. The skill flags multi-subsystem scope and splits it into sequenced sub-projects.

ForFounders and leads who describe the whole product in a single sentence.

The prompt

I want to build a creator platform: chat, file storage, billing, and analytics. Use the brainstorming skill. Before refining any details, assess scope. If this is several independent subsystems, say so, decompose it into sub-projects, tell me how they depend on each other and the order to build them, then brainstorm only the first sub-project through the normal design flow.

What slides.md looks like

Scope check: this is 5 independent subsystems, not one project.
Decomposing before we design anything:

  1. identity + accounts   (no deps — build first)
  2. chat                  (deps: 1)
  3. file storage          (deps: 1)
  4. billing               (deps: 1)
  5. analytics             (deps: 2, 3, 4 — build last)

Each sub-project gets its own spec -> plan -> implementation cycle.
Starting with #1 (accounts). Q1 of that brainstorm:
  What identity model — email/password, SSO-only, or both?

One-line tweak

Swap the ordering line for 'sequence by risk, not dependencies' if you want to de-risk billing early instead of building the dependency graph bottom-up.

Pairs with

writing-plans

Each decomposed sub-project flows into its own task-gated plan.

linear

Turn the sub-project list into tracked epics so the decomposition isn't lost.

Weigh 2-3 architecture approaches with a recommendation

Settle a single architecture decision with real trade-offs and an opinionated recommendation — not a wishy-washy 'it depends.'

ForEngineers at a fork in the road who want the options named before they commit.

The prompt

Use the brainstorming skill for exactly one decision: how should we run background jobs in our Rails app? Give me 2-3 approaches with honest trade-offs, lead with the one you'd pick and why, and stop there — this is the approaches step, not the full design. No code.

What slides.md looks like

Background jobs — 3 approaches (recommendation first):

A) Solid Queue (Postgres-backed)   <- recommended
   + no new infra; transactional with your existing DB
   - throughput ceiling vs Redis at very high volume
B) Sidekiq + Redis
   + battle-tested, high throughput   - adds Redis to ops
C) Managed (SQS + workers)
   + scales infinitely   - vendor lock-in, local-dev friction

Recommend A: you're at ~200 jobs/min; Postgres handles that and
you avoid running Redis. Revisit B only past ~5k jobs/min.

One-line tweak

Add 'and sketch each option as a Mermaid diagram' to have the visual companion render the three data flows side by side instead of describing them.

Pairs with

mermaid

Diagram the three options so the trade-off is visual, not just prose.

writing-plans

Plan the option you picked once the approach is settled.

Pressure-test module boundaries before you write them

Catch a tangled design before it becomes code — force every module to pass the 'what does it do, how is it used, what does it depend on' test.

ForAnyone whose last feature turned into one 900-line file. The boundary check that prevents the sequel.

The prompt

Here's my rough plan for notifications: one NotificationManager that formats, batches, sends, retries, and logs. Use the brainstorming skill's design-for-isolation check. For each proposed unit tell me what it does, how it's used, and what it depends on. Flag anything doing too much and propose tighter boundaries so each unit can be tested independently. Don't write code yet.

What slides.md looks like

Boundary review — your single NotificationManager does 5 jobs.
Splitting into units that can each be tested in isolation:

  formatter     does: text/HTML from a template   depends: templates
  batcher       does: group by user + window       depends: a clock
  sender        does: one channel send             depends: provider SDK
  retry-policy  does: backoff decision             depends: nothing (pure)

Boundary test: can you change the batcher's internals without
touching the sender? Now yes. Before, no — that's why it was one file.

One-line tweak

Add 'and mark which units are pure functions' — pure units (retry-policy) get the cheapest tests, so it's worth planning them first.

Pairs with

drawio-diagrams-enhanced

Draw the unit boundaries and their interfaces as a diagram.

writing-plans

Each well-bounded unit becomes its own testable task in the plan.

Brainstorm a change inside an existing (messy) codebase

Add a feature to a legacy service without ignoring its patterns or rewriting half of it. The skill explores first, follows the grain, and scopes only the improvements the work needs.

ForEngineers working in code they didn't write and can't rewrite this quarter.

The prompt

We need to add webhook retries to our billing service (legacy, ~5 years old). Use the brainstorming skill. Explore the current structure and its patterns first, then follow them. Where the existing code genuinely blocks the work — e.g. the 600-line BillingController — propose a targeted improvement, but don't scope any refactoring that doesn't serve retries. Present the design in sections.

What slides.md looks like

Explored the repo first. Existing patterns I'll follow:
  - service objects in app/services/*   (not fat controllers)
  - Result objects, not exceptions, for control flow

Design (with the grain):
  - new WebhookRetryJob mirrors the existing RefundRetryJob
  - reuse the Result pattern already in PaymentGateway

Targeted improvement (needed for this work): extract WebhookSender
out of the 600-line BillingController — the retry loop can't be
tested while it lives inside the controller.
Out of scope: the rest of BillingController stays as-is.

One-line tweak

Drop the 'targeted improvement' clause if you want a purely additive change and the smallest possible diff for review.

Pairs with

github

Read the repo's real patterns and recent commits before proposing anything.

writing-plans

Turn the design that follows existing patterns into a task-gated plan.

Turn 'make it better' into concrete requirements

Convert a mushy stakeholder ask into a crisp set of requirements you can design against — one answerable question at a time.

ForAnyone handed 'our search is bad, make it better' with no other detail.

The prompt

Stakeholder ask: 'our in-app search is bad, make it better.' Use the brainstorming skill. Don't propose anything yet — first pin down purpose, constraints, and success criteria by asking me one question at a time, multiple choice where possible. Stop after about five questions and play back the requirements you've captured before we look at approaches.

What slides.md looks like

Q1 — What's "bad" today? (pick the biggest one)
  a) irrelevant results   b) too slow
  c) misses recent items  d) no typo tolerance
> a and c

Q2 — Success looks like...?
  a) top result correct ~90% of the time
  b) results under 200ms   c) both
> a

Captured so far -> purpose: relevance, not speed.
constraint: keep current infra. success: top-1 correct 90%
on our real query log. Next: 2-3 ranking approaches (no code yet).

One-line tweak

Add 'keep going until you're 90% confident you could write the spec' to trade a few more questions for a tighter requirements set.

Pairs with

notion

Drop the captured requirements straight onto the project page.

writing-plans

The agreed requirements become the plan's global constraints.

Use the visual companion to settle a layout decision

Decide a UI question by looking at real mockups in a browser tab instead of arguing about it in prose. The skill offers the companion only when a question is genuinely visual.

ForAnyone brainstorming a screen where 'which layout?' is a see-it question, not a describe-it one.

The prompt

We're designing an onboarding wizard. Use the brainstorming skill. When we hit a genuinely visual question — like which wizard layout works — offer the visual companion so I can compare mockups in a browser, and keep the conceptual questions (what a 'step' means, validation rules) in the terminal. Walk me through it one decision at a time.

What slides.md looks like

Conceptual (terminal): how many steps, and can users skip ahead?
> 3 steps, no skipping.

Visual (this one's clearer shown than told):
> "This next part might be easier if I show you — I can put
   together mockups, diagrams, and comparisons in a browser tab
   as we go. Want me to? I'll open it for you."
   [you accept] -> tab opens:
     left-rail  vs  top-stepper  vs  single-scroll
Pick the layout in the tab; the conceptual choices stay in here.

One-line tweak

Decline the companion and the whole session stays text-only — the skill won't offer again unless you raise it. The gate is per-question, not a mode.

Pairs with

mermaid

Flowchart the wizard's step transitions alongside the mockups.

drawio-diagrams-enhanced

Turn the chosen layout into a wireframe you keep with the spec.

Run a YAGNI pass to cut a bloated feature list to the wedge

Take a 12-feature 'v1' wishlist and cut it to the smallest thing that ships value — with the skill defending each cut out loud.

ForTeams whose v1 has quietly become a v3. The scope knife.

The prompt

Here's the feature list for our 'v1' comments system: threading, reactions, mentions, markdown, edit history, moderation queue, spam ML, export, i18n, real-time, read receipts, pinning. Use the brainstorming skill and apply YAGNI ruthlessly. Cut to the smallest v1 that delivers the core value, tell me what you cut and why, and what's a deliberate 'later.' Then present the trimmed design.

What slides.md looks like

YAGNI pass on 12 features -> v1 is 3:

KEEP (the core value): post a comment, threading, markdown
LATER (real, just not now): reactions, mentions, edit history
CUT (until proven needed): spam ML, read receipts, pinning,
     export, i18n, real-time, moderation queue

Why: the wedge is "discuss in context." Everything else is
weight until people actually comment. Ship 3, learn, then revisit
the LATER list with real usage instead of guesses.

One-line tweak

Add 'assume 100k daily active users' and the skill keeps more — moderation queue and spam ML move from CUT to LATER once abuse is a real risk at that scale.

Pairs with

writing-plans

Plan only the three features you kept — the LATER list stays out of the plan.

linear

File the LATER items as backlog so they're captured, not lost.

Self-review the spec before it becomes a plan

Catch the TBDs, contradictions, and two-way-readable requirements in a design doc before they turn into bugs in the plan.

ForAnyone about to hand a spec to a teammate or a subagent that will take it literally.

The prompt

Read docs/superpowers/specs/2026-07-09-saved-views-design.md. Run the brainstorming skill's spec self-review: scan for placeholders (TBD/TODO), check the sections don't contradict each other, check it's scoped to a single plan, and flag any requirement that could be read two ways — then rewrite those to be explicit. Fix inline and show me the diff. Don't start the plan yet.

What slides.md looks like

Spec self-review — the four checks:

[placeholder]   "cache TTL: TBD"        -> set to 60s (matches the API)
[contradiction] §2 says "per-user",
                §4 says "per-team"      -> picked per-user; fixed §4
[scope]         one plan's worth? yes.
[ambiguity]     "views load fast"       -> "P95 < 150ms on the
                                           500-issue fixture"

Fixed inline. The spec is now unambiguous and internally consistent.
Ready for your review before we write the plan.

One-line tweak

Add 'and run writing-clearly-and-concisely over it' to tighten the prose too, not just the logic — the SKILL.md names that companion by hand for exactly this.

Pairs with

writing-clearly-and-concisely

The spec-prose companion the brainstorming SKILL.md references for the written design.

github

Commit the reviewed spec so the plan is built on the fixed version.

Enforce the hard gate — no code before an approved design

Make 'no code before an approved design' a rule the agent enforces on itself — even when you (or it) are tempted to skip straight to implementation.

ForAnyone who has watched an agent start editing files ten seconds into a vague request.

The prompt

For this whole session, enforce the brainstorming skill's hard gate: do not write code, scaffold, or run any implementation skill until we've brainstormed a design and I've approved it — no matter how simple the task looks. If I ask you to jump to code, refuse and tell me why, then take me back to the design. When the spec is approved, hand off to writing-plans and nothing else.

What slides.md looks like

> "just add the endpoint, skip the design"

Holding the gate. The brainstorming skill blocks implementation
until there's an approved design — and this applies even to a
one-endpoint change, because that's exactly where an unexamined
assumption hides. Two questions and you'll have a spec to approve.

...[design approved]...

-> Spec committed. Invoking writing-plans — the only next step.
   (Not frontend-design, not any other implementation skill.)

One-line tweak

This gate is the whole point — but for a true one-line fix, just don't invoke brainstorming. Reach for test-driven-development or edit directly; the ceremony isn't free.

Pairs with

using-superpowers

The anchor skill that makes Claude actually fire the gate instead of ignoring it.

writing-plans

The single skill brainstorming transitions to once the design is approved.

Community signal

Three voices that frame why a brainstorming skill exists at all. The first names the problem — models don’t stop to ask. The second is the skill doing its job — a hard gate refusing to code. The third is why the resulting design doc keeps the agent on track.

“The largest problem I have with LLMs is that they are seemingly incapable of stopping to ask clarifying questions.”

nightski · Hacker News

From the Superpowers launch thread. This is the problem the brainstorming skill exists to fix — it makes stopping to ask the default, one question at a time.

“I watched Claude refuse to write code I asked it to write, because the design doc wasn't approved yet. A flat refusal, with the rationale spelled out in plain English, citing a hard gate inside something called the brainstorming skill.”

Tommaso Nervegna · Blog

A designer's adoption story — the brainstorming skill's hard gate doing exactly what use case 10 promises. (Lightly trimmed to length; full text on the page.)

“The technique of maintaining a design document and a plan/progress document that get updated after each change seems to make a big difference in keeping the LLM on track.”

wrs · Hacker News

Why the artifact matters. The brainstorming skill's whole output is that design document — committed to docs/superpowers/specs/ before any code is written.

The contrarian take

Not everyone thinks a brainstorming skill needs to exist. The sharpest version of that objection, from the launch thread, is simonw (Simon Willison):

“I think the asking clarifying questions thing is solved already. Tell a coding agent to "ask clarifying questions" and watch what it does!”

simonw (Simon Willison) · Hacker News

From the Superpowers launch HN thread.