Process
/brainstormingClarify consequential choices before you build.
The tempting first move
A rough request contains hidden decisions
Imagine asking an AI agent, “Build a dashboard for orders at risk.” The request sounds clear until construction begins. Which orders count as at risk? Who uses the dashboard? What decision should it support? May it contact customers, or only show information? The first line of code can quietly answer all four questions without you noticing.
Structured clarification changes the order. Before building, the agent explores the situation, asks focused questions, compares possible approaches and writes down what has been agreed. The result is a small specification, or spec: a plain description of the intended behaviour, boundaries and evidence of success. The diagram calls this brainstorming. The enduring method is simply to turn assumptions into decisions before they become implementation.
Clarify the choice before implementation
A rough request becomes buildable when consequential ambiguity is converted into an approved decision artifact.
- Describe the desired change State the user, moment and outcome without prescribing every detail.
- Surface hidden choices Ask about rules, failure, permissions, scope and trade-offs.
- Compare options Show consequences instead of asking open-ended preference questions.
- Approve a mini-spec Record the chosen behaviour and boundaries.
- Grant implementation authority Build only after the consequential choices are visible.
Clarification ends in an artifact that implementation and tests can inspect.
The enduring method
Clarify, compare, specify, then approve
The method has four moves. First, inspect the available context: the current process, users, data and constraints. Second, ask one useful question at a time until the consequential gaps are visible. Third, offer two or three approaches and explain what each optimises or gives up. Fourth, write a short spec and ask the responsible person to approve or correct it.
This is sometimes called a Socratic approach, meaning that understanding develops through questions rather than a lecture. The name matters less than the discipline. A good question changes a decision. A poor question merely makes the conversation longer.
A useful mini-spec names the goal, user, inputs, rules, output, exclusions, owner and acceptance criteria. Acceptance criteria are observable conditions that let someone check whether the result behaves as agreed.
A complete business example
From “build a dashboard” to an approved decision
Take the order-dashboard request as a hypothetical conversation.
Owner: “Build a dashboard that shows orders at risk.”
Agent: “Who will use it, and what decision should it help them make?”
Owner: “The operations lead checks it each morning and decides which orders need intervention.”
Agent: “What makes an order at risk?”
Owner: “It is due within 48 hours and stock has not been allocated, or its latest courier scan is more than 24 hours old.”
Agent: “Should the first version act on an order?”
Owner: “No. It should show the reason and link to the order. No automatic messages, refunds or cancellations.”
Agent: “I see three approaches: a live dashboard, a daily email or a spreadsheet export. The dashboard is easier to inspect throughout the day; email is simpler but becomes stale; the export is flexible but creates another file to manage. Which trade-off fits?”
Owner: “Use the dashboard. Refresh it every 15 minutes.”
Only now is there enough information to design responsibly. The questions exposed the user, decision, risk rules, data freshness and authority boundary. This kind of early alignment also explains why the surrounding human system often takes longer than the first technical prototype.
Ambiguity becomes harder to reverse as it travels
The shape is conceptual, not a universal cost curve. Commitment adds dependencies and people.
- Question A wrong interpretation costs a conversation.
- Mini-spec A wrong rule costs a small revision.
- Implementation Code, tests and data begin to depend on the choice.
- Release Users and operations adapt to the behaviour.
- Institutionalisation Reports, training and contracts can make reversal expensive.
Resolve consequential ambiguity at the cheapest boundary that can still expose it.
What the gate leaves behind
Approval needs something concrete to approve
The agent turns that conversation into a mini-spec:
Goal: help the operations lead identify orders requiring intervention.
Inputs: order due date, stock-allocation state and latest courier scan, refreshed every 15 minutes.
Rules: flag either risk condition and show which one fired.
Output: a filterable list with order link, promised date and reason.
Out of scope: customer messages, refunds, cancellations and automatic order changes.
Acceptance criteria: agreed sample orders appear or stay hidden correctly; each flagged row shows its evidence; users without operations access cannot open the page.
Agent: “Does this describe the first version you are authorising?”
Owner: “Add cancelled and test orders to the exclusions.”
Agent: “Updated. Is this the approved first-version spec?”
Owner: “Yes. Proceed.”
That approval completes the example. The spec is now a durable decision record, not proof that the future software works. It should travel into planning, tests and review, and change through an explicit revision when the business learns something new. This is the same reason an organisation benefits from a governed memory it can inspect instead of reconstructing intent from old messages.
How you actually use it
Keep the method separate from the tool
Superpowers has packaged this pattern as a brainstorming skill. Command names, trigger rules and exact steps belong to that product and can change between releases. None of them is the method itself.
You can use the method with any capable agent or with two people at a whiteboard. A practical instruction is: “Before building, inspect the context and ask one clarifying question at a time. Offer two or three approaches with trade-offs. Then write a mini-spec covering the goal, user, inputs, rules, output, exclusions, owner and observable acceptance criteria. Wait for approval before implementation.”
Where the method bends
A spec can still preserve the wrong idea
Clarification is not magic. The agent can ask shallow questions, the owner can supply a mistaken rule, and an approved spec can exclude someone whose needs were never represented. For consequential work, involve the people affected and a domain expert. Approval records authority; it does not manufacture correctness.
The ceremony should also fit the risk. A spelling correction may need one sentence, not a workshop. A new payment rule deserves deeper questions, examples, failure cases and a rollback plan. The cost curve is conceptual rather than measured: misunderstandings often become more expensive after they spread into code, data and operations, but not every late change is a rewrite and not every early conversation is cheap.
The bottom line
Make uncertainty visible before it becomes work
The purpose of brainstorming is not to make the agent sound thoughtful. It is to expose choices while they are still easy to discuss. A rough request becomes a decision, the decision becomes a spec, and the spec becomes a testable boundary for the work that follows.
As a professional, I want the person who owns the outcome to approve those boundaries. As a student, I want the questions to reveal what we do not yet know. The practical rule is simple: when a request leaves consequential choices unstated, do not let speed conceal them. Clarify first, record the agreement and build only what someone is prepared to own.
Sources & caveats. Superpowers is an open-source project by Jesse Vincent and contributors. It is one implementation of the clarification method described here, not the source of the underlying practice. Product behaviour, commands and installation details change, so this essay does not serve as current product documentation. For the current implementation, see the Superpowers repository (github.com/obra/superpowers).