Brainstorming
Run structured design dialogue and get explicit approval before your agent writes code or scaffolds anything.
Overview
Brainstorming is a journey-wide agent skill that explores user intent, requirements, and design through dialogue and blocks implementation until a solo builder approves the design—usable whenever you need to decide what
Install
npx skills add https://github.com/obra/superpowers --skill brainstormingWhat is this skill?
- HARD-GATE: no code, scaffolding, or implementation until design is presented and approved
- 9-step checklist: context → questions → approaches → design → spec → review → sign-off
- Applies to every project—even trivial todos need a brief approved design
- Optional visual companion for mockups, diagrams, and layout comparisons
- Terminates by invoking writing-plans to create the implementation roadmap
- 9-step design checklist from context exploration through user sign-off
- HARD-GATE: no implementation until design is approved
Adoption & trust: 209k installs on skills.sh; 221k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to add features or change behavior in an agent session without an examined design, so assumptions slip straight into code and rework piles up.
Who is it for?
Solo builders starting any creative change—new features, UI, components, or behavior—who want a enforced design pause before the agent touches the repo.
Skip if: Skip when a written spec is already approved and you only need execution—not when a task feels small or trivial.
When should I use this skill?
You MUST use this before any creative work—creating features, building components, adding functionality, or modifying behavior—and when exploring user intent, requirements, and design before implementation.
What do I get? / Deliverables
You get an approved design or spec in docs/superpowers/specs/; then invoke writing-plans as the only next skill in the Superpowers stack.
- Presented design (brief or detailed) with explicit user approval
- Documented requirements and design decisions captured in the session (and design doc when your workflow saves one)
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Brainstorm product directions and UX assumptions after reading competitor notes before you commit to a build stack.
Walk through MVP boundaries and user flows one question at a time, then present a design for approval before prototyping code.
Explore layout and component behavior with an optional visual companion message before any scaffold or implementation skill runs.
Shape a non-trivial UX or behavior change discovered in pre-release review into an approved mini-design before patching.
Clarify intent and tradeoffs for a meaningful iteration feature instead of letting the agent patch production behavior ad hoc.
How it compares
Use this structured approval gate instead of letting the agent jump from chat intent to code without a presented design.
Common Questions / FAQ
Who is brainstorming for?
Solo and indie builders using agentic coding tools who want a consistent design-first ritual before features, components, or behavior changes land in the codebase.
When should I use brainstorming?
Use it before any creative work—in Validate when scoping an MVP, in Build when designing a component or integration, in Idea when exploring product direction, at Ship when reshaping launch-critical UX, and in Operate when planning non-trivial iteration—until you have presented a
Is brainstorming safe to install?
It is procedural guidance for dialogue and gating, not a hidden auto-deploy tool; review the Security Audits panel on this Prism page and read SKILL.md in your fork before enabling it in automated pipelines.
Workflow Chain
Then invoke: writing plans
SKILL.md
READMESKILL.md - Brainstorming
# Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs through natural collaborative dialogue. Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval. <HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE> ## Anti-Pattern: "This Is Too Simple To Need A Design" Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval. ## Checklist You MUST create a task for each of these items and complete them in order: 1. **Explore project context** — check files, docs, recent commits 2. **Offer visual companion** (if topic will involve visual questions) — this is its own message, not combined with a clarifying question. See the Visual Companion section below. 3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria 4. **Propose 2-3 approaches** — with trade-offs and your recommendation 5. **Present design** — in sections scaled to their complexity, get user approval after each section 6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit 7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below) 8. **User reviews written spec** — ask user to review the spec file before proceeding 9. **Transition to implementation** — invoke writing-plans skill to create implementation plan ## Process Flow ```dot digraph brainstorming { "Explore project context" [shape=box]; "Visual questions ahead?" [shape=diamond]; "Offer Visual Companion\n(own message, no other content)" [shape=box]; "Ask clarifying questions" [shape=box]; "Propose 2-3 approaches" [shape=box]; "Present design sections" [shape=box]; "User approves design?" [shape=diamond]; "Write design doc" [shape=box]; "Spec self-review\n(fix inline)" [shape=box]; "User reviews spec?" [shape=diamond]; "Invoke writing-plans skill" [shape=doublecircle]; "Explore project context" -> "Visual questions ahead?"; "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"]; "Visual questions ahead?" -> "Ask clarifying questions" [label="no"]; "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions"; "Ask clarifying questions" -> "Propose 2-3 approaches"; "Propose 2-3 approaches" -> "Present design sections"; "Present design sections" -> "User approves design?"; "User approves design?" -> "Present design sections" [label="no, revise"]; "User approves design?" -> "Write design doc" [label="yes"]; "Write design doc" -> "Spec self-review\n(fix inline)"; "Spec self-review\n(fix inline)" -> "User reviews spec?"; "User reviews spec?" -> "Write design doc" [label="changes requested"]; "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"]; } ``` **The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans. ## The Process **Understanding the idea:** - Check out the current project state first (files, docs, recent commi