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.

Every frustrated "the agent doesn't get it" I've watched in the wild traces back to the same source. Not the model. The brief. The brief was a wish, not a definition. The agent guessed at the parts the brief didn't pin down, and the guesses were wrong.

The fix isn't a smarter model. It's a brainstorming discipline you do with the model before any code gets written. I encoded mine as a skill the agent runs on itself. It's standalone and free. You can install it in about thirty seconds.

The bug nobody calls a bug

Watch what happens when someone tells an agent "build me a CLI to archive old files."

A capable agent will start writing. It will pick a language. It will pick where the archives go. It will pick what "old" means. It will pick whether the threshold is configurable. Every one of those is a decision the human should be making, and the agent is making them silently because nothing in the prompt told it not to.

By the time the human reads the output, they're not reviewing a design. They're reviewing four decisions and a script. They push back on one of the decisions and the agent rewrites the whole thing. The script becomes a referendum on choices that should have been resolved in the brief.

The thing that's broken isn't the agent's coding. It's the missing step before the coding.

Brainstorming isn't a vibe, it's a method

The version of brainstorming most people do with AI is a vibe. A loose chat to "explore the idea" before the real work starts. The output is a hand-wave.

The version that works is a discipline. Nine steps, one rule that does most of the work, and one hard gate that makes the rest of it possible. The output is a spec document that lives in your repo, with the human's signature on it.

When this is in place, three things change:

The disagreements surface early. Changing direction costs five minutes instead of five hours.

The model stops guessing. The spec exists. Anything not in the spec is explicitly out of scope.

You catch your own bad assumptions out loud. That's the only way you ever catch them.

The walker

Click each step to flip it. The flip shows the rule, plus the specific anti-pattern that step exists to prevent. Try to drag one out of order.

The one rule that does the most work

One question per message.

Not "tell me about your project." One specific clarifying question, multi-choice when possible. Wait for the answer. Ask the next one.

This is slow. It is slow on purpose. Every batched question burns context. It also lets the answer to question one shape the answers to two and three before you've had a chance to consider them in isolation. The cost of a batched question isn't the time it saves. It's the answers you give that you'd have given differently if the questions had been separated.

Slow at the gate, fast through the build.

The hard gate

After step 5, the agent is forbidden from writing code, scaffolding files, invoking implementation skills, or doing anything past "present the design." It can only continue if you say "approved."

The gate is the whole reason the rest works. Without it, every previous step is theatre. The agent will brainstorm with you, draft a beautiful design, then immediately ignore it and build whatever it was already going to build.

The hard gate makes the design load-bearing. The human's "approved" is the only key.

What this skill doesn't do

It doesn't write code. It doesn't pick frameworks. It doesn't generate tests. The terminal state is the approved spec plus an implementation plan, both written to disk.

Implementation happens in a separate session against the written plan. That separation is the point. The implementer reads the spec cold and builds against a written agreement, not a half-remembered chat. The brainstorming session does its job, writes its artefacts, and ends.

How to install it

The skill is one folder. Four markdown files plus a small Node.js script for the optional visual companion. No package manager. No external services. No telemetry. No sibling skill dependencies.

For Claude Code at the user level, drop the folder at ~/.claude/skills/brainstorming/. That's the whole install. The full INSTALL.md inside the zip covers Cursor, generic LLM use, and the visual companion.

The visual companion

If your upcoming questions are layouts, mockups, or side-by-side designs, the skill can launch a small localhost server that watches a directory for HTML mockups and serves the newest one to your browser. You click options in the browser, the agent reads the click events on its next turn.

Per-question decision, not per-session. The skill uses it only when "would the human understand this better by seeing it than reading it?" is yes. Conceptual questions stay in the terminal. The companion is bundled in the zip; nothing to install separately.

The takeaway

The model isn't the bottleneck. The brief is. Fix the brief and the rest gets out of the way.

The brainstorm is the build. Everything after it is execution.