Brainstorming with Superpowers

What it does

This is the intent-discovery stage of the Superpowers workflow. It starts by reading the project and previous decisions so that questions concern real gaps, rather than facts already supplied. It distinguishes a fully specified small change from a project whose audience, constraints or purpose are unsettled. The reviewed source asks for concrete alternatives and explicit design approval, then hands the agreed design to writing-plans. Its optional visual companion supports mockups when seeing alternatives would help the user decide.

When to use it

• Define the behavior of a new onboarding flow whose success criteria are unclear.
• Compare a lightweight extension with a separate service before funding development.
• Translate a business request into a design another engineer can implement.

Step-by-step workflow

1. Read the existing product, relevant files and prior decisions; list only uncertainties that could change the outcome.
2. Ask one specific question at a time, starting with the user’s purpose and intended audience.
3. Compare two or three viable approaches with concrete trade-offs; record the selected approach and assumptions.
4. Write a proportionate design covering goals, exclusions, constraints and decisions; obtain approval before building.
5. For a project, use the source’s builder check to expose unanswered decisions, then hand the approved design to writing-plans.

Example request

Use brainstorming to design a first-run setup for our invoicing app. Read the existing onboarding and account model first. We want new freelancers to issue their first valid invoice without entering irrelevant company settings. Ask only questions that change the design. Compare a single setup page with progressive setup, show the key screen flow, record your assumptions and write the design for approval before implementation.

Worked example

Suppose new freelancers abandon setup at the tax-details screen. The useful first question is which tax information is legally needed for the first invoice, not which animation looks nicer. A design might postpone optional branding while requiring the jurisdiction and invoice identity. The document should show the mandatory path, the optional exit and invalid-input handling. A mockup can reveal whether the sequence makes sense, but does not establish conversion improvement; that needs user observation or measured rollout.

What you get

An agreed design document, explicit approach comparison, recorded assumptions and a clear transition to implementation planning.

How to evaluate the result

• The design names the audience, success criteria and required behavior.
• Assumptions are distinguishable from decisions the user actually approved.
• Every remaining implementation decision can be made without inventing product requirements.

What you need

A product brief, access to relevant project material and a decision-maker who can clarify intent. The optional companion needs an appropriate local browser/server environment.

Setup and activation

The publisher documents separate installation routes for Claude Code, Codex App and CLI, Cursor and other harnesses. Use the README for your exact client; installing the whole Superpowers framework can activate additional workflows automatically. Preserve this skill’s companion files and relative references. Review and security-scan the exact selected version before installation. This directory only reviews sources; it has not installed, executed or tested this skill on those clients. Read visual-companion.md before enabling that optional feature and inspect its hosting and telemetry settings.

Limits and considerations

The source deliberately adds approval gates and can be too heavy for a precisely specified cosmetic edit. It allows an explicitly agreed throwaway spike and an opt-out from the discovery conversation. The visual companion is optional; its README documents a remotely loaded logo containing version information and telemetry opt-out controls. This is design guidance, not usability research.

Related workflows

• Use writing-plans to turn the approved design into testable tasks.
• Use webapp-testing or a usability study to validate the implemented flow.

License and reuse

MIT, copyright 2025 Jesse Vincent. Preserve the copyright and permission notice when redistributing substantial source portions; inspect separately supplied dependencies and assets under their own terms.

Further reading

• Reviewed skill version (immutable commit)
• Publisher setup, compatibility and telemetry notes
• Reviewed MIT license