What does this skill do, and when should you use it?
Brainstorming is the design-refinement skill in obra/superpowers. It examines project context, asks focused questions about goals and constraints, and turns the discussion into a validated design. It blocks implementation work until the user approves that design. The approved result is written as a specification and handed off to the planning workflow.
Checks project files, documentation, and recent commits; asks one question at a time to refine intent, requirements, constraints, and success criteria; presents 2–3 approaches with trade-offs; presents architecture, components, data flow, error handling, and testing in reviewable sections; after approval, writes a design specification, commits it to Git, and transitions to the implementation-planning workflow.
- A developer has a rough feature idea and needs requirements and boundaries clarified before coding.
- A team needs to compare several implementation approaches and approve one before work starts.
- A change to an existing codebase requires inspection of its structure, documentation, and recent history first.
- A small configuration change or utility still carries assumptions that should be surfaced before implementation.
How do you install this skill?
- Before adoption, verify that writing-plans and the required agent tools are available, and define a text-only fallback for unavailable dependencies.
- Before using the visual companion remotely or in a container, verify bind address, access controls, session keys, and network exposure; do not expose the service publicly by default.
- For simple configuration changes or one-line fixes, assess whether the full brainstorming, documentation, commit, and approval chain is proportionate.
- The skill does not clearly specify Chinese-language interaction, sensitive project-data handling, or recovery after a failed commit.
- Shell / CLI
- Network access
- Local filesystem
Git
This skill is distributed as part of the Superpowers collection, which bundles 14 skills. Install the collection separately for the coding harness you use: in Claude Code, run /plugin install superpowers@claude-plugins-official; in Antigravity, run agy plugin install https://github.com/obra/superpowers; in Pi, run pi install git:github.com/obra/superpowers. The repository README documents other harnesses; no standalone installation command is provided for this skill.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/obra/superpowers.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/brainstorming" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
After installing the collection, use it for requests involving new features, components, added functionality, or behavior changes. It first explores context and asks clarifying questions, then compares approaches, presents the design, and waits for approval. SKILL.md does not define a dedicated trigger prompt or standalone command.
What are this skill's strengths and limitations?
- Creates an explicit pre-coding gate for requirements, alternatives, design review, and approval.
- Covers architecture, components, data flow, error handling, and testing in the design review.
- Starts with existing project context, making it suitable for changes in established codebases.
- It deliberately delays code, scaffolding, and other implementation actions until design approval, which may add overhead to very small tasks.
- It depends on the separate writing-plans workflow to continue toward implementation.
- The supplied source does not document an independent test suite or cross-platform validation for this skill.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Design Before Code this page | 50 · Use with care | ★ 299k | 16d ago | MIT |
| Continuous Code Review | 53 · Use with care | ★ 299k | 16d ago | MIT |
| Executing Plans | 54 · Use with care | ★ 299k | 16d ago | MIT |
| Writing Plans | 53 · Use with care | ★ 299k | 16d ago | MIT |
| Compound Engineering Brainstorm | 61 · Recommended | ★ 26k | 11d ago | MIT |
How did FollowSkills review this skill?
The skill requires user approval before implementation and makes the visual companion opt-in after approval. Supporting scripts show session-key authentication, restrictive file permissions, cross-origin checks, and guarded shutdown behavior. Deductions apply because the workflow mandates writing and committing a design document without specifying pre-commit confirmation, rollback, or recovery; the visual companion's local server, browser, event writes, and telemetry boundaries are not fully disclosed within the skill.
The ordered workflow, terminal state, reconnection behavior, restart guidance, invalid-argument handling, and stale-PID protection are reasonably explicit. Deductions apply because the skill depends on writing-plans, harness-specific tools, and browser support without a defined fallback when those dependencies are unavailable; static evidence does not reproduce the complete key path, so the score is capped below 10.
The intended scenario is clear: an agent clarifies requirements and obtains design approval before implementation. It distinguishes textual questions from visual questions and documents several agent environments. Deductions apply because the trigger is overly broad and mandates the full process for nearly every change, with no clear non-fit range; Chinese-language interaction is not addressed, and remote or restricted-network reachability of the visual companion requires extra host configuration.
The documentation has clear layering, hard gates, a checklist, a flow diagram, limitations, examples, visual-companion guidance, and cleanup instructions. Repository context supplies an MIT license, a package version, and maintenance channels. Deductions apply because the skill itself has no version, changelog, dependency-install notes, or explicit maintenance owner, and it assumes downstream skills such as writing-plans are available.
The skill can turn an underspecified request into a user-approved design, a specification document, and a transition to implementation planning; its main outputs are reasonably clear. Deductions apply because the mandatory process can be disproportionate for simple tasks, while document writing, commits, and downstream skill invocation depend on external tools and user cooperation; no representative complete output is statically verified, so the score remains at or below 7.
The flow diagram, script interfaces, event format, and shutdown behavior are auditable, and the supplied repository context includes security tests for the companion server. Deductions apply because there is no independent execution evidence or focused test suite covering the conversational workflow, approval gates, and produced design documents; nothing was executed for this review, so only limited static verifiability is justified.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →