The Brainstorm Skill

The gap nobody talks about

Every useful thing I’ve ever shipped started as a fuzzy idea I couldn’t quite explain. And every one of them almost died in the same place: the gap between “I think there’s something here” and “here’s a plan I can actually execute.”

You know the gap. It’s the one where you open a blank doc, stare at it, and either:

Write three bullet points that are too vague to act on, or
Jump straight into implementation and realize three hours later you built the wrong thing.

I’ve been working on closing that gap for a while. Whiteboards, Notion templates, mind maps, voice memos, “idea showers” in the car. They all help a little. None of them solved it.

What finally did? A Claude Code skill called brainstorm. It’s the most unglamorous, high-leverage tool in my kit right now, and I want to walk you through exactly how it works and why it matters.

What the skill actually is

If you use Claude Code, you already know about skills. They’re reusable, named prompts that turn Claude into a specialist for a specific workflow. The brainstorm skill is one of those. You type /brainstorm [topic] and Claude stops being a generic assistant and starts being a structured interviewer.

The whole skill is five phases, run in order, with strict rules about how Claude behaves at each one:

Seed. Capture the initial idea.
Discovery. Understand goals, context, motivation.
Exploration. Dig into constraints, tradeoffs, alternatives.
Expansion. Add bold, unexpected suggestions.
Crystallize. Produce a validated plan document.

That probably sounds like a framework you’ve seen before. The difference is in the enforcement. Each phase has rules, and the rules are what make it work.

The rules that make it different

Here are the core rules from the skill file, paraphrased:

Every question uses a structured question tool. No freeform “so tell me about…” prompts. You get multiple-choice options (or multi-select), plus an “Other” escape hatch.
One question at a time during Discovery, Exploration, and Expansion.
You control pacing. Claude will never auto-advance to the plan-writing phase. It offers suggestions, asks if you want more, and waits.
Phase transitions are announced. You always know where you are: “Phase 2: Discovery.”
Expansion is bold on purpose. Claude is explicitly told to suggest ambitious, unexpected ideas, not just safe ones.
Adaptive everything. The questions, the plan sections, the suggestion categories. All of it shapes itself to what you’re actually brainstorming. It doesn’t assume software.
Never trust training data for package versions. If you mention a library, Claude verifies the current version, security status, and alternatives using live docs and search. No hallucinated “v3.1 is the latest” nonsense.
A verbatim transcript is maintained throughout. Every question, every answer, every observation, logged to a file after each step.

That last rule is the quiet superpower. Keep reading.

How a session actually feels

Here’s what a real brainstorm looks like from the user’s side. I’ll use an example from my own work: a CLI tool for managing dotfiles across machines.

Phase 1: Seed. Claude restates the idea and asks one clarifying question. “What’s the primary pain point this tool should solve?” I pick: keeping configs in sync across multiple machines. Done. Moves on.

Phase 2: Discovery. One question at a time. How many machines? What are you using now? What’s the friction? Each question is multiple-choice, so I don’t have to compose answers. I just pick. This is faster than it sounds, and more importantly, the options Claude generates often surface considerations I hadn’t thought of. “Oh right, I hadn’t considered whether I want read-only backups or two-way sync.”

If the topic is related to a project I’m working on, Claude runs a codebase scan in the background and grounds the next questions in what it found. That’s the “Explore” subagent doing work while I think.

Phase 3: Exploration. Now it’s digging into tradeoffs. Simplicity vs. flexibility? Platform support? Non-goals? This is where I usually discover I was about to build something more ambitious than I need. Or less ambitious than the problem requires.

If I mention a library (say, “I’m thinking Node.js with Commander”), Claude quietly looks up the current version, checks for CVEs, and might come back with: “I looked into Commander.js. v13 just dropped with breaking changes to option parsing. Want to pin to v12 or migrate?” This is table stakes for a senior engineer and completely missing from generic chat-with-an-LLM workflows.

Phase 4: Expansion. This is where it gets fun. Claude presents 3-4 bold suggestions as a multi-select: “Machine profiles that auto-apply per device type.” “Encrypted secret management.” “A plugin system for community recipes.” “Diff preview before syncing.”

I pick what resonates, skip what doesn’t, add my own. Claude asks if I want more ideas or if I’m ready to crystallize. I usually run two or three rounds. Some of the best features I’ve ever shipped came from round-two expansion suggestions I would never have generated on my own.

Phase 5: Crystallize. Claude shows an outline of what the plan will cover. I approve or adjust. Then it writes the plan, with adaptive sections, no rigid template, and verified version numbers for every dependency.

And then, this is the part I love, it launches a second agent whose entire job is to compare the plan against the full transcript. Did anything I said during Discovery not make it into the plan? Did Claude gloss over a constraint? The reviewer finds gaps, surfaces them to me as yes/no/modify questions, and the loop repeats until the reviewer returns PLAN_COMPLETE.

That two-agent pattern, one to produce and one to audit, is how you catch the stuff that falls out of working memory during a long session. It’s also how Claude catches itself being lossy.

Why this matters more than it looks

On the surface, this is “AI asks you questions about your idea.” That’s not a new concept. Socratic prompting has been a thing since, well, Socrates.

What’s actually happening underneath is more interesting, and it’s why I think this pattern is going to spread:

1. It offloads the hardest part of brainstorming: knowing what to ask. The reason staring at a blank doc is paralyzing is that you have to simultaneously generate ideas and generate the meta-questions that would surface better ideas. The skill handles the second job. I just answer.

2. It forces structured output without feeling like a form. Because Claude uses a question tool with options, my answers are already semi-structured. By the time we get to Crystallize, the plan writes itself from data that’s already organized. No “let me turn this conversation into a doc” cleanup step.

3. The transcript is the safety net. Every brainstorm I’ve ever done in a meeting or a doc has lost something. A great idea from minute 20 that nobody wrote down. A constraint the user mentioned in passing that got glossed over. The verbatim transcript, updated after every single interaction, means nothing is lost. Even if the session crashes halfway through, the file on disk has every exchange.

4. The reviewer agent is a new kind of quality gate. LLMs are good at generating content. They’re less good at noticing what’s missing from content they just generated, because their attention is on what’s present. Launching a fresh agent with no context except “here’s the transcript, here’s the plan, what’s in the first that’s not in the second?” gives you a clean-slate check that catches exactly the things the generating agent couldn’t see.

5. Live version verification kills a whole class of bugs. “Claude said to use X but X is deprecated” is one of the top complaints about AI-assisted development. The skill bakes live lookup into the workflow, so the plan you walk away with references today’s reality, not January 2026’s training data.

The unexpected benefits

A few things I didn’t expect when I started using the skill regularly:

It’s a better interviewer than I am. When I brainstorm with collaborators, I either ask leading questions or meander. Claude, constrained by the skill’s rules, does neither. It’s more neutral than I’d be with myself.

Expansion phase generates ideas I’d reject if I’d thought of them first. Because the suggestions come from “outside,” I evaluate them on their merits rather than on the ego-friction of whether they were mine. Several shipped features started life as Expansion suggestions I almost dismissed.

It’s phenomenal for decisions that aren’t software. I’ve used it to brainstorm a hiring scorecard, a content calendar, a restructuring of my week. The “adaptive everything” rule means Claude doesn’t default to engineering-shaped answers when the problem isn’t engineering-shaped.

Handoff to implementation is frictionless. At the end, Claude offers two options: start implementing now, or generate a copy/paste handoff prompt for a different session or tool. The handoff prompt includes the plan summary, key decisions, verified tech stack, and instructions for the implementing agent. That’s a clean seam between “figured out what to build” and “building it.”

Where it fits in a workflow

I use brainstorm at a very specific point: when I have enough of an idea to know it’s worth pursuing, but not enough to know what I’m actually committing to. Too early, and Claude is asking questions I can’t answer. Too late, and I’ve already made decisions the interview would have challenged.

The sweet spot is this: I could describe this idea in two sentences, but if you asked me five follow-up questions I’d stammer. That’s when the skill earns its keep.

I do not use it for:

Tasks with known scope (just do the task)
Exploratory research (/research is a different skill, purpose-built for that)
Anything I’ve already planned and just need to execute

It’s a hammer, and most problems aren’t nails. But when they are, nothing else I’ve tried is close.

What I’d like to see next

The pattern is extensible, and I’m watching to see where it goes:

Multi-participant brainstorms. Could two people run a shared brainstorm with Claude mediating? The transcript architecture is already halfway there.
Brainstorm, research, plan pipelines. The ecosystem already has /research and /research-to-plan. Chaining them with /brainstorm as the front door feels inevitable.
Persistent topic memory. Right now each brainstorm is standalone. Imagine Claude remembering context across brainstorms on related topics, compounding insight instead of starting from zero.

The bigger insight

Here’s what I keep coming back to. The skill isn’t really about brainstorming. It’s about the fact that the structure of your thinking process is itself a tool, and you can hand that tool to an AI to run on your behalf.

For decades, we’ve used AI as a content generator: “write me a thing.” The brainstorm skill is a different shape. It uses AI as a process conductor. The content (the ideas, the decisions, the plan) still comes from me. What Claude provides is the discipline to actually walk through the process without cutting corners, forgetting to consider alternatives, or skipping straight to implementation.

That’s the 42 Insight, if there is one: the next wave of AI leverage isn’t going to come from asking models to do more thinking for us. It’s going to come from giving them the structure of our thinking and letting them enforce it when our own discipline falters.

I keep losing ideas in the gap between spark and plan. The brainstorm skill is the first tool I’ve used that actually closes it.

First published April 19, 2026 on 42 Insights.