An export button can mean downloading the current table or designing background jobs, permission boundaries, and large-file delivery. Brainstorming helps establish which problem the team is solving before implementation begins.
Install and start
Run the following plugin command inside a Claude Code session to install Superpowers, including its cooperating skills. In Codex, find Superpowers in the plugin interface and install it there. Install separately for each client you use. Start a fresh session in the project and explicitly ask to use brainstorming with a bounded task.
/plugin install superpowers@claude-plugins-official
Match the process to the change
Adapt this first request to your project:
Use Superpowers brainstorming for an export feature in our existing order dashboard. Read current filters, permissions, and data-volume constraints, decide whether this is bounded work or a new subsystem, and clarify the scope step by step. Propose a design before writing implementation code.
The current skill distinguishes feasibility exploration, bounded changes, and architectural work. A feasibility spike can end with an answer and disposable experimental code. A small, well-understood change can use a brief design approved in conversation. Architectural work needs a fuller comparison and written design. Not every request requires a long specification.
Provide the existing code, intended users, and success criteria. For order export, useful questions include who can export, whether the file contains the current page or all filtered results, and what happens at large volumes. The agent should use project context and advance one important question at a time rather than presenting an unrelated generic questionnaire.
Agree on tradeoffs
For architectural work, the process compares alternative approaches and presents the design in manageable sections. Correct assumptions about data flow, failure handling, and excluded scope as they appear. A synchronous download may be sufficient for a small dataset, while larger jobs may need a different design; the skill cannot determine that requirement without context.
A full specification normally goes under docs/superpowers/specs with a dated filename. The approved design can then move to writing-plans for implementation planning. Review the saved document before proceeding, because agreement during conversation does not guarantee every constraint survived into the document. State existing documentation conventions before the file is created.
Recognize a useful stopping point
The result may be an answered feasibility question, a short approved local design, or a reviewed architectural specification. It need not include production code. If the discussion keeps expanding, separate independent requests and finish the smallest useful deliverable first. The optional visual companion is useful for visual decisions, not a requirement for every discussion.
You still supply business decisions. When evidence is missing, a visible unresolved question is more useful than an invented answer. When context already resolves a question, the process should use it instead of repeatedly asking for the same information.
Another example: turn a vague reminder idea into a reviewable design
If the request is “remind users when they forget a task,” show the agent the existing notification entry points, time-zone handling, opt-out rules, and definition of incomplete. Ask it to decide whether this is a local change or a new scheduling system. An in-app reminder from an existing due-date field may need only a short design; cross-time-zone email with retries and frequency caps needs a more architectural choice. Discuss when the reminder is created, how duplicates are prevented, and how users turn it off as distinct questions.
Walk a specific path through the proposal: a user sets a task on Friday, changes time zone, and completes it before a Sunday deadline. Would a stale reminder still arrive? If the design cannot answer, it is not ready to become an implementation plan. An exploratory path may conclude that usage data is missing; record the needed measurement and smallest experiment. Only after a design is accepted should writing-plans break it into tasks. Brainstormed alternatives are not all approved requirements.
Read the existing product before ideating
For an existing product, provide the real constraints first: relevant components, data shapes, current UI, and interactions that must remain. One user found that brainstorming for a Next.js UI kept inventing components and mocks until they paused, explored the actual code, and fed those shapes back into the discussion. Add this to the first request: “Read these files and summarize the existing shapes before proposing a design; if you cannot find them, list the unknowns rather than inventing components.” The resulting decisions will fit the product you have.