I've started every feature I've built in the last few months the same way: I don't open an editor first. I open a terminal and run a brainstorm.
Here's what that actually looks like — not just "it asks questions," but what comes out the other side.
What Claude Code is
Claude Code is Anthropic's CLI — runs in your terminal, reads your files, edits code, runs commands, works through multi-step tasks. It has full context on your actual project instead of starting from a blank slate every time.
The Superpowers plugin extends it with structured workflows. Brainstorming is one of them. You invoke it with /brainstorm and it walks you through what you're building before you touch a single file.
What it actually does
It reads your existing codebase first. Then it asks questions — one at a time — about purpose, constraints, users, success criteria. Once it understands the scope, it proposes 2-3 approaches with trade-offs and a recommendation.
The approaches aren't abstract. If you're building a UI component, it'll show you layout options in the browser. If you're designing an API, it'll sketch out the endpoint structure. If you're planning a refactor, it'll map out which files need to change and in what order.
Example 1 — a UI feature
I needed a table of contents for blog posts. My instinct was to hardcode it manually per post. The brainstorm asked: should this be opt-in per post, or auto-generated from headings? Should it float alongside the content or sit inline above it? Sticky on scroll or static?
Three layout options came back as actual rendered mockups in the browser — sidebar float, inline block, collapsible dropdown. I picked the inline version in about 30 seconds instead of building the wrong one and redesigning it later.
The whole decision took 5 minutes. Implementation was another 10.
Example 2 — an architecture decision
Adding GTM to a Ghost blog with an existing cookie consent banner. The question wasn't "how do I add a script tag." It was: should GTM load unconditionally and use Consent Mode internally, or should the snippet itself only load after consent?
The brainstorm laid out both approaches: load-always with Consent Mode v2 (Google's recommended path, works with GTM's built-in consent signals) vs. deferred load (simpler, but breaks GTM's consent mode timeline). It flagged that Germany has stricter enforcement than the rest of the EU and recommended the Consent Mode v2 path with default-denied state.
That's the kind of thing you'd spend an hour reading blog posts to figure out. It came up in the second question.
Example 3 — a refactor
A Node.js script had grown to 400 lines with mixed concerns — DB queries, business logic, and formatting all in one file. The brainstorm asked: is this a one-off script or does it need to be maintainable long-term? Are there tests? What's the deployment context?
It came back with three options: minimal split (extract just the DB layer), full separation (three files with clear interfaces), or no split but internal cleanup with better function names. It recommended the minimal split with a concrete file structure — what goes where, what each file exports, what the call chain looks like.
No code written yet. Just a clear map.
How to run it
/brainstormIt detects your project context automatically from files and recent commits. For a new idea with no existing code, just describe what you want to build and it takes it from there.
If visual questions come up — layouts, component placement, diagram-worthy architecture — it'll offer to show them in a browser tab. You can decline and stick to text if you prefer.
When it's worth it
Anything where you could reasonably make a wrong decision at the start: new features, UI work, architecture changes, refactors, content strategy. The brainstorm is most useful when there's genuine ambiguity about approach — not just implementation details.
Skip it for one-line fixes or changes where there's only one sensible way to do it.
The honest take
The value isn't speed. It's catching wrong assumptions before they become wrong code. The "I built this for a day and it solves the wrong problem" mistake is the expensive one — and it's the one this prevents.
Ten minutes of questions is a cheap trade for two hours of rework.
