$ ~/registry/skill/obra-brainstorming

SKILL

brainstorming

Name: brainstorming
Author: obra

Clarify intent, requirements, and solution direction before any creative implementation work.

Stars

★ 244,334

Source

GitHub

Updated

2026-07-02

// securityCaution

Prompt only, no code
Open source

Summary

The material indicates this is essentially an open-source prompt-only brainstorming/workflow skill with no required secrets and no declared remote endpoints, so overall risk is low. The README does instruct checking project files, writing a design doc, and committing changes, but these appear to be workflow directions rather than standalone execution capability, which warrants only limited caution.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required, and there is no visible request to collect or store tokens, API keys, or other credentials, leaving minimal credential exposure.

Network egressLow risk

No remote endpoints or external service calls are declared; based on the provided material, there is no indication that user data is sent to third-party network destinations.

Code executionLow risk

The system flags it as prompt-only, and the material itself is a set of workflow constraints and dialogue instructions; although it mentions later invoking other skills and committing a design doc, it does not show that this skill itself can spawn local processes or execute code.

Data accessCaution

The README instructs users to 'check files, docs, recent commits' and save a design under `docs/superpowers/specs/...`, indicating an expected workflow that reads project context and writes repository files; this is a typical skill data-access pattern with no clear signs of over-privileged access.

Supply chainCaution

It comes from an open-source GitHub repository, which is a clear risk-reducing factor due to auditability; however, the license is unspecified, stars are 0, and maintenance status is unknown, so community validation and upkeep evidence are weak, warranting some supply-chain caution.

Recommendations

Try it first in a restricted repository or test branch to confirm it is only used for design discussion and does not trigger extra implementation actions.
If following the README to write design docs or create commits, manually review the proposed content and change scope first.
Check the repository history, maintenance activity, and license status before adopting it into a formal workflow.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "brainstorming" skill from askskill:
1. Download https://raw.githubusercontent.com/obra/superpowers/main/skills/brainstorming/SKILL.md
2. Save it as ~/.claude/skills/brainstorming/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Requirement clarification before development

Prompt

I need to add a bulk refund feature to an e-commerce admin panel. Do not write code yet. First, brainstorm the user goals, key scenarios, edge cases, risks, and possible UX and technical approaches.

Expected

A structured requirement and solution outline covering goals, scenarios, constraints, risks, and implementation directions.

Solution exploration before component design

Prompt

I want to design a reusable date filter component. First, brainstorm usage scenarios, user interaction patterns, state design, accessibility requirements, and API options, then recommend an approach.

Expected

A comparison of multiple design options and a recommended component approach suitable for implementation.

Impact assessment before behavior changes

Prompt

I want to change the sending logic of an existing notification system. Before making changes, brainstorm the possible impacts on user experience, business rules, failure cases, rollback strategy, and testing priorities.

Expected

A change impact assessment and pre-implementation checklist to help make the update safely.

// docs

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:

Explore project context — check files, docs, recent commits
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.
Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
Propose 2-3 approaches — with trade-offs and your recommendation
Present design — in sections scaled to their complexity, get user approval after each section
Write design doc — save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and commit
Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
User reviews written spec — ask user to review the spec file before proceeding
Transition to implementation — invoke writing-plans skill to create implementation plan

Process Flow

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 commits)

…

View full docs ↗

Implement features and fixes by writing tests before production code.

obraGet→

$ loading_

Please install the "brainstorming" skill from askskill: 1. Download https://raw.githubusercontent.com/obra/superpowers/main/skills/brainstorming/SKILL.md 2. Save it as ~/.claude/skills/brainstorming/SKILL.md 3. Reload skills and tell me it's ready

// examples

Requirement clarification before development

Prompt

I need to add a bulk refund feature to an e-commerce admin panel. Do not write code yet. First, brainstorm the user goals, key scenarios, edge cases, risks, and possible UX and technical approaches.

Expected

A structured requirement and solution outline covering goals, scenarios, constraints, risks, and implementation directions.

Solution exploration before component design

Prompt

I want to design a reusable date filter component. First, brainstorm usage scenarios, user interaction patterns, state design, accessibility requirements, and API options, then recommend an approach.

Expected

A comparison of multiple design options and a recommended component approach suitable for implementation.

Impact assessment before behavior changes

Prompt

I want to change the sending logic of an existing notification system. Before making changes, brainstorm the possible impacts on user experience, business rules, failure cases, rollback strategy, and testing priorities.

Expected

A change impact assessment and pre-implementation checklist to help make the update safely.

// docs

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.

Anti-Pattern: "This Is Too Simple To Need A Design"

Checklist

You MUST create a task for each of these items and complete them in order:

Explore project context — check files, docs, recent commits
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.
Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
Propose 2-3 approaches — with trade-offs and your recommendation
Present design — in sections scaled to their complexity, get user approval after each section
Write design doc — save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and commit
Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
User reviews written spec — ask user to review the spec file before proceeding
Transition to implementation — invoke writing-plans skill to create implementation plan

Process Flow

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 commits)

…

View full docs ↗