Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarydiscipline and process / 2026-05-17

The brainstorm is the build

If your AI keeps confidently building the wrong thing, the bug isn't in the model. It's in the gap between what you asked for and what done looks like.

9 parts / Hover to explore. Click to read.

If your AI keeps confidently building the wrong thing, the bug isn't in the model. It's in the gap between what you asked for and what done looks like.

Question -> answer -> refine
                    |
             proposed design
                    |
             human approval
                    |
               spec + plan
                    |
            new build session
The skill stops at the proposed design until the human approves. This is a working instruction and review boundary, not an operating-system security control.
Download the brainstorming skill (zip, ~25KB)

When an agent confidently builds the wrong thing, look at the decisions it had to make without you.

You may have had a very clear picture in your head. That doesn't mean the brief contained it. If the brief leaves gaps, the agent has to guess or ask. A fast implementation can hide how many guesses it made.

I built a brainstorming skill to make those decisions visible before the coding starts. It's standalone, free, and available below. Its output is a written design you can agree to and an implementation plan somebody else can pick up.

Notice the decisions inside a small request

Take “build me a CLI to archive old files”.

What counts as old? Where should the archives go? Which language fits the workspace? Can the threshold change? What happens to the source files?

The request looks small. The decisions inside it are not. If the agent chooses silently, you end up reviewing a script and a set of assumptions at the same time. Changing one assumption may mean rewriting most of the script.

Have that conversation while the work is still a design. It is much easier to correct a sentence than to untangle a tool built around the wrong behaviour.

9-step brainstorming pipeline with hard gate after step 5HARD GATE1Explore2Visual3Question4Approach5Design6Write doc7Self-review8Human review9Plan
The 9-step flow. The vertical line is the hard gate. Nothing crosses it without explicit human approval.

Give the conversation an output

An open conversation can help you explore an idea. For a build, I also want it to end somewhere definite.

This skill has nine steps, an approval gate, and a spec saved in the repository. The design records the choices. The gate gives the human a chance to accept them before implementation begins.

That does three useful things. Disagreements show up while they are cheap to resolve. The agent has a written boundary for the work. And I have to say my assumptions out loud, which is often when I discover they don't make much sense.

Anything outside the approved spec is out of scope until we make a new decision. The agent shouldn't quietly turn an interesting extra into part of the build.

Try the steps below. Flip a card to see its rule and the failure it is there to prevent. Try dragging one out of order as well.

step 1

Explore project context

→

Read the files, docs, and recent commits before asking anything. Skip this and your first three questions will be ones you could have answered yourself.

Jumping straight to "so what do you want to build?"

step 2

Offer visual companion

→

If upcoming questions are visual (mockups, layouts, diagrams), offer the browser companion. In its own message. Wait for consent.

Combining the offer with a clarifying question, or never offering it for genuinely visual work.

step 3

One question at a time

→

Multi-choice when possible. Wait for the answer before asking the next. Focus on purpose, constraints, success criteria.

A paragraph with four questions in it that the user partially answers and you misread.

step 4

Propose 2 or 3 approaches

→

Lead with your recommendation and the reasoning. Show trade-offs. Conversational, not a wall of bullets.

Picking one approach without showing what you ruled out.

step 5

Present design in sections

→

Scale each section to its complexity. Get approval after each. Cover architecture, components, data flow, error handling, testing.

A 1500-word design dump that requires the human to find the wrong parts.

step 6

Write the design doc

→

Save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md (or wherever the project keeps specs). Commit it.

A design that lives only in the chat scrollback.

step 7

Spec self-review

→

Re-read with fresh eyes. Fix placeholders, contradictions, ambiguity, scope drift. Inline.

Shipping a spec with three "TBD"s and a section that contradicts the architecture.

step 8

Human reviews the spec

→

Ask the user to read the written doc and approve before any planning. Wait.

Treating chat-level approval as written-spec approval.

step 9

Produce the implementation plan

→

From the approved spec, write a step-by-step plan. Implementation happens in a separate session against the plan, not the chat.

Jumping straight from "design approved" to writing code in the same session.

// drag to reorder. they snap back. you can't shortcut the process.

Ask one question, then listen

One question per message.

That's the rule I get the most use from. Ask a specific question, offer choices when the decision has clear options, and wait for the answer before deciding what to ask next.

A batch of questions looks efficient. It can also give me a form to fill in when what we need is a conversation. The answer to the first question may make the next three irrelevant.

One at a time gives me room to consider the decision and lets the agent adjust. Use an open question when we're still finding the shape. Use a scope check before designing something that may not belong in the build.

Three question shapes: multi-choice, open-ended, scope-checkMulti-choiceStorage: local-only, cloud, or hybrid?decisions with discrete optionsOpen-endedWhat does 'done' look like for the first release?shape questions, no obvious option setScope-checkIs this one project or several stacked together?before designing, when the request might be multiple projects
Pick the shape of the question before asking it. Multi-choice for discrete decisions. Open for shape questions. Scope-check before designing anything.

Make approval a real boundary

After step five, this skill stops at the proposed design. Its instructions prohibit implementation, scaffolding and invoking implementation skills until the human explicitly approves.

That pause matters. I need to see the design we actually arrived at, not discover it later in a diff. Once I've approved it, the next steps can record the spec and prepare the implementation plan.

The gate is an instruction inside the skill. It is not an operating-system security boundary. It gives the agent a clear rule and gives you a clear point at which to check what it is proposing.

Hard gate: steps 1-5 (unlocked) vs steps 6-9 (locked behind design approval)DESIGN PHASE1. Explore context✓2. Offer visual companion✓3. One question at a time✓4. Propose approaches✓5. Present design✓design approval requiredIMPLEMENTATION PHASE6. Write design doc⚿7. Spec self-review⚿8. Human reviews spec⚿9. Implementation plan⚿No code, no scaffolding, no implementation skill until the human approves the design.
The skill requires explicit design approval before implementation can continue.

Keep planning and implementation legible

This skill does not write the application, generate its tests or make framework choices on your behalf. It ends with an approved spec and an implementation plan on disk.

Implementation then starts in a separate session. That session reads the agreement as a document. It shouldn't need to infer what you meant from a half-remembered conversation.

The separation is useful even when the same model does both jobs. You can inspect what was agreed and what was built, and see where they differ.

Install the folder

The download contains one skill folder: four Markdown files and a small Node.js script for the optional visual companion. It has no package-manager setup, external service, telemetry or sibling-skill dependency.

For a user-level Claude Code install, put it at ~/.claude/skills/brainstorming/. Read the included INSTALL.md for Cursor, generic LLM use and the visual companion.

↓Download the brainstorming skill (zip, ~25KB)

Use pictures when the decision needs them

The optional companion starts a small localhost server. It watches a folder of HTML mockups and shows the newest one in your browser. You can click an option there; the agent reads the click events on its next turn.

Use it for layouts, mockups and designs you need to compare visually. A question about the purpose of the product can stay in the conversation. Decide per question whether seeing it would help.

The companion is included in the download. You don't need a separate service.

Try it on a real uncertainty

Choose a build where you can describe the idea but aren't yet sure what done looks like. Let the skill ask its first question. Answer that one, then see what the answer changes.

The useful result is a design you understand well enough to approve and a plan that carries it into the next session. That's a much better starting point than asking for another version and hoping this one will be closer.

[ comments ]

guests welcome. members show first in the list

members

  • I cannot agree more: It is slow on purpose - You need to be slow at the gate in order to be fast through the build. Just wow.

    member (Frontier) OG · Sat, 08 Aug 2026 19:15:40 GMT

1 / 11