> ## Content Index > Fetch the complete content index at: https://blog.sudowl.com/llms.txt > Use this file to discover other available public pages before exploring further. # Claude Code Superpowers: How I Brainstorm Features Before Writing a Single Line - URL: https://blog.sudowl.com/claude-code-superpowers-brainstorming/ - Published: 2026-04-09T12:00:00.000Z - Updated: 2026-10-11T08:47:37.000Z - Description: How the Superpowers plugin for Claude Code forces a design step: one question at a time, 2-3 approaches, a written spec, then a plan. Install and workflow. - Author: Lukas - Tags: AI The worst thing an AI coding agent does isn't writing bad code. It's writing *a lot* of reasonable-looking code for the wrong thing, fast, before you've finished explaining what you meant. Superpowers fixes that by making Claude Code stop and ask before it builds. **TL;DR:** install the plugin, describe a feature, and let it interrogate you before it touches a file. ```text /plugin install superpowers@claude-plugins-official ``` Or via the author's own marketplace: ```text /plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace ``` Restart Claude Code, describe what you want to build, and the brainstorming skill kicks in: questions one at a time, a few approaches with trade-offs, a design you approve in chunks, a spec file in the repo — and only then a plan and code. ## What Superpowers actually is Superpowers is an open-source collection of **skills** for coding agents, written by Jesse Vincent (`obra/superpowers` on GitHub). A skill is a Markdown file with instructions that the agent loads when the situation matches its description. Claude Code supports skills natively; the plugin just ships a well-designed set of them plus a bit of startup glue so the agent actually checks for them. The skills cover the whole development loop. The ones I care about most: - **brainstorming** — turn a vague idea into an agreed design before any code. - **writing-plans** — turn the approved design into a step-by-step implementation plan. - **subagent-driven-development** / **executing-plans** — work through the plan, either by dispatching subagents per task or inline. - **test-driven-development**, **systematic-debugging**, **verification-before-completion** — the discipline layer: tests first, root cause before fixes, evidence before "done". This post is about the first one, because it's the one that changed how I work. Skills evolve between versions — what I describe is how the brainstorming skill behaves in the version I run. Read the `SKILL.md` in your install if something looks different. ## How the brainstorming skill works You say something like "I want to add X". Instead of opening an editor, Claude: 1. **Looks around first.** Reads the relevant files, docs, recent commits. Read-only. 2. **Classifies the job.** Current versions sort the request into a quick feasibility *spike*, a *bounded* change to existing code, or an *architectural* change (new project, new subsystem, changed interfaces) — and say the classification out loud so you can overrule it. Bounded work gets a short design in chat; architectural work gets the full process below. 3. **Asks questions — one per message.** Often multiple choice. Purpose, constraints, what success looks like. One at a time is deliberate: you answer properly instead of skimming a wall of ten questions. 4. **Proposes 2-3 approaches** with trade-offs and a recommendation. YAGNI is explicitly part of the instructions — it's supposed to cut features, not add them. 5. **Presents the design in sections** and asks after each one whether it's right. 6. **Writes a design doc** into the repo (`docs/superpowers/specs/YYYY-MM-DD--design.md` by default), commits it, and asks you to review the file. 7. **Hands off to writing-plans.** Not to code. The plan comes next, and you approve that too. The important part is the gate: the skill says no implementation — no code, no scaffolding, no installing dependencies — until you've approved the design for that path. In my experience Claude takes that seriously. It will stop and wait. ## What it looks like in practice Here's an illustrative example — paraphrased and shortened, not a real transcript — of the kind of exchange you get. Say I ask for "a Discord ping when my nightly backup script fails": ```text Me: Add a Discord alert to backup.sh when the backup fails. Claude: [reads backup.sh and the systemd timer that runs it] This looks bounded: one existing script, one new failure path. I'll ask a couple of questions, then show a short design here. Question 1: what counts as "failed"? a) non-zero exit of the whole script b) rsync exit code only c) also warn if the backup is suspiciously small Me: a, keep it simple. Claude: Question 2: where should the webhook URL live? a) environment file read by the systemd unit b) hardcoded in the script c) separate config file next to the script Me: a. Claude: Design: trap ERR/EXIT in backup.sh, on non-zero exit POST a short message (host, exit code, last 20 log lines) to the webhook from $DISCORD_WEBHOOK. EnvironmentFile= in the unit. No retries — if Discord is down, the journal still has it. OK to implement? ``` Two questions, a three-line design, a yes/no. That's the bounded path. For something bigger — say, a new tool with its own service, storage and API — you get more questions, actual alternative architectures, and a spec file you can read in a normal editor. If you want the actual alerting pattern from that example, I wrote it up separately: [Discord alerts from server logs with systemd](/discord-alerts-server-logs-systemd/). ## Why I like it **It catches the questions I didn't know I had.** Half the value is the questions themselves. "What counts as failed?" is the decision that determines whether the feature is useful, and I hadn't thought about it when I typed the request. **The spec outlives the session.** Context windows end, sessions get compacted. A Markdown spec committed to the repo doesn't. Next session — or next month — "read the spec in docs/superpowers/specs and continue" just works. **It makes the plan reviewable.** Reviewing a design doc takes a few minutes. Reviewing 600 lines of generated code to reverse-engineer what design it implies takes much longer, and you miss things. **It's honest about scope.** If a request is really three projects, the skill is supposed to say so and split it before refining details. That alone keeps "build me a dashboard" from turning into an afternoon of half-finished everything. ## How I combine it with the rest of my setup Superpowers handles *process*. The rest of my Claude Code setup handles *guardrails* and *context*: - [Hooks](/claude-code-hooks-automate-workflow/) auto-format every edit and block dangerous Bash. The same notify script can hang off the `SubagentStop` event if you want a ping when one of the subagents that subagent-driven-development dispatches finishes. - An [MCP server with read-only sysadmin tools](/build-mcp-server-sysadmin-tools/) means that during the "look around first" step, Claude can check the actual box instead of guessing. - For small throwaway jobs — a one-off PowerShell script — I skip the ceremony and use a [constraint-heavy prompt](/how-i-use-claude-powershell-scripts/) instead. Prompt templates for that are in the [sysadmin prompt cheat sheet](/sysadmin-ai-prompt-cheatsheet/). ## Gotcha: it's slower, on purpose If you're used to "type request, get code", the first few sessions feel like bureaucracy. Answering five questions for a feature you think is obvious is annoying. Then you notice how often your "obvious" feature had an unasked question in it. If something truly is a one-liner, say so — the bounded path is short, and you can always push back on the classification. ## Gotcha: answer the question it asked Because it asks one question at a time, it's tempting to dump everything in your first answer. Don't, or at least don't expect it to skip ahead — it'll still walk its list. Answer what was asked; add "also: X matters" if something important hasn't come up yet. ## Gotcha: approval means approval "Looks good" to a design section is approval of *that section*. It's not "go build everything". The skill is written so that approving the design lets it write the spec, approving the spec lets it write the plan, and so on. If you want it to move faster, say explicitly what you're approving. And if it ever starts writing code without your yes, stop it — that's the process breaking, not a feature. ## Gotcha: tokens More turns, more reading, a spec, a plan — this costs more tokens than just generating code. For me the trade is worth it because rework is the expensive part. But if you're on a tight API budget, keep an eye on it; I wrote about where agent costs actually come from in [AI agent API costs and background loops](/ai-agent-api-costs-background-loops/). ## Bottom line The model is good at writing code. It's bad at knowing which code you want. Superpowers' brainstorming skill puts a short, structured conversation in between — and that conversation is where bad feature ideas die cheaply instead of late. --- ### Related posts - [Building an MCP Server to Give Claude My Sysadmin Tools](https://blog.diengdoh.com/build-mcp-server-sysadmin-tools/?ref=blog.sudowl.com) - [Claude Code Hooks — Automating the Boring Parts of My Workflow](https://blog.diengdoh.com/claude-code-hooks-automate-workflow/?ref=blog.sudowl.com) - [How I Use Claude to Write PowerShell Scripts in 30 Seconds](https://blog.diengdoh.com/how-i-use-claude-powershell-scripts/?ref=blog.sudowl.com)