Grounded thinking partner — turn a vague thought, question, or “help me understand this” into clarity, anchored in this repo’s calibrated knowledge base (populated by running /calibrate first — the skill still works on uncalibrated projects, but answers lean more generic).
/brainstorm [thought | question]
Alternate invocations: /help me think, /wondering, /what if, /should we even, /not sure — all trigger the same skill.
superpowers:brainstorming (it ends by writing a design doc). /brainstorm is for when you don’t know what you want yet — it’s upstream of intent; it routes you to those other skills once your thinking sharpens./brainstorm I keep thinking we should refactor the payments module
What you’ll see: one clarifying question, a reflection grounded in your project’s calibrated
knowledge (cited from project-profile.md, conventions.md, domain.md, etc.), an explicit
“in this repo X / generically Y” contrast, one or two hidden assumptions called out, and a
closing choice — dig deeper, converge to a summary, or hand off to the right skill. It never
writes code or files on its own.
For example, on a direct question, one line of the reply looks like:
In this repo: we have inbox-queue (Redis, at-least-once) and system-bus (Kafka, exactly-once).
Generically: the tradeoff is operational simplicity vs delivery guarantees and replay-ability.
When your intent sharpens, /brainstorm offers (never auto-invokes) the matching downstream skill:
| Your signal | Suggested handoff |
|---|---|
| “I want to build / spec a feature” | /planning <name> |
| “The spec exists, ready to build” | /implement <name> |
| “Just want to drive one concrete objective to done, fast” | /goal <objective> |
| “Something’s broken / a bug” | /fix <description> (or /incident if severity unclear) |
| “I need to find code / where is X” | /explore <query> |
| “Broad orientation to this repo” | /onboard or /scan |
| “Competitors / market signal” | /market-research |
| “Product / feature framing” | /opportunity-map |
| “Tech debt suspicion” | /tech-debt <scope> |
| “Performance concern” | /perf <scope> |
| “Should we even do this?” | Stay in /brainstorm — that’s this skill’s job |
/brainstorm what's the difference between our two queue systems? # grounded explanation, repo-vs-generic
/brainstorm what if we let users tag projects with custom labels? # half-formed idea → probes intent, may steer to /planning
/brainstorm should we even build a mobile app? # existential — stays in /brainstorm, that's the job
/brainstorm # no args → prompts "What's on your mind?"
.claude/project-profile.md, .claude/knowledge/shared/*.md, .claude/knowledge/external/sources.md, and CLAUDE.md before answering, so every response is grounded in (or explicitly contrasted against) project reality. The skill works on any project — it just gives grounded, repo-specific answers only if your project has been calibrated via /calibrate first; otherwise it says so up front and leans generic. A size guard lazy-loads deep content for very large KBs./planning, /implement, /fix, /explore, /tech-debt, /perf, …) but never auto-invokes it — a user-confirmation checkpoint.If the project hasn’t been calibrated (no project-profile.md), it says so up front and notes
its answers will lean generic — run /calibrate first for repo-grounded responses.
/brainstorm is a thinking mode, single-agent, no fan-out..claude/knowledge/shared/<area>.md.Negligible (~2 units) — a single agent, no fan-out, one set of parallel file reads on entry
(bounded by a size guard so large knowledge bases lazy-load instead of front-loading), then
turn-based responses. An accepted handoff to another skill bears that skill’s own cost, and
an accepted knowledge-base write-back at convergence is a single small append.
/brainstorm is deliberately cheap so it can be the friction-free front door.
| Problem | Fix |
|---|---|
| Answers feel generic, not repo-specific | The project isn’t calibrated — run /calibrate so the knowledge base exists. |
/brainstorm: thought or question required as positional arg in non-interactive mode. Exiting. |
You ran it with no argument under CI=true/CLAUDE_AUTOPILOT=1. Pass a thought: /brainstorm <your thought>. |
| It keeps asking questions instead of acting | By design — it’s a thinking partner, not an executor. Accept a handoff (e.g. /fix, /planning) when you’re ready to act. |
Confused with superpowers:brainstorming |
Use /brainstorm when you’re not sure what you want; use superpowers:brainstorming when you’re set on building X and want a design doc first. |
/brainstorm idea crystallizes into a feature/brainstorm grounds its answers in/brainstorm sits among the toolkit’s entry points