Using v7 of the plugin with Claude Code, all results mention are from Opus 5.5.
Since I started using superpowers I have always used the brainstorming skill as the entrypoint to all work. I usually use it even when there's an existing spec file or partially completed design, with my intent being "ensure this work is well defined, spec is accurate, up to date, and complete." This does seem to be what the skill has driven models to do, and this flow has worked very well.
v7's changes that force model to ask questions during brainstorming lead to some odd interactions. Here are some things I've experienced in the last 24 hours:
- Working on a spec that was up into three PR's (part A, B, C),
/brainstorming Implement part B of @spec-nameresults in, "I see that part A of was recently implemented. How was your experience making that change? Did you learn any lessons you want to apply to part B?" - In a repo that tracks tech debt items (usually not a full spec, often needs design decisions), fixing a piece of tech debt is normally
/brainstorming Review and fix @tech-debt-doc. Now that consistently results in a question like, "What made you decide to fix ? Was it a bug report from a user, or ?" - In a library whose entire purpose is managing an application's sql queries stored in sql files (instead of strings in the application), prompt
/brainstorming Review the integration test coverage on <feature>. Does it have coverage with a variety of queries that are realistically complex to represent what will be encountered in a real-world app?, I got the question "What kind of queries do you think users will prefer? Hand written or ORM generated?"
I don't think that "say the word to skip questions" is an acceptable escape hatch to avoid this. All of my experience with LLMs screams that telling a model "skip questions" is likely to lead it to makes its own decisions about implementation direction or technical choices where I do want input.
I can see how this approach could be useful to less technical users or those who really are starting with only a broad idea of what they want to do. But I suspect that many of your users are like me - technical people who are using brainstorming to flesh out the details of a relatively focused task. I do wonder if these questions might be better suited to an ideation skill that's tuned for high level planning.
tl;dr, please don't make us waste time and tokens with these questions.
Activity
24Good
Using v7 of the plugin with Claude Code, all results mention are from Opus 5.5.
Since I started using superpowers I have always used the brainstorming skill as the entrypoint to all work. I usually use it even when there's an existing spec file or partially completed design, with my intent being "ensure this work is well defined, spec is accurate, up to date, and complete." This does seem to be what the skill has driven models to do, and this flow has worked very well.
v7's changes that force model to ask questions during brainstorming lead to some odd interactions. Here are some things I've experienced in the last 24 hours:
- Working on a spec that was up into three PR's (part A, B, C),
/brainstorming Implement part B of @spec-nameresults in, "I see that part A of was recently implemented. How was your experience making that change? Did you learn any lessons you want to apply to part B?"- In a repo that tracks tech debt items (usually not a full spec, often needs design decisions), fixing a piece of tech debt is normally
/brainstorming Review and fix @tech-debt-doc. Now that consistently results in a question like, "What made you decide to fix ? Was it a bug report from a user, or ?"- In a library whose entire purpose is managing an application's sql queries stored in sql files (instead of strings in the application), prompt
/brainstorming Review the integration test coverage on <feature>. Does it have coverage with a variety of queries that are realistically complex to represent what will be encountered in a real-world app?, I got the question "What kind of queries do you think users will prefer? Hand written or ORM generated?"I don't think that "say the word to skip questions" is an acceptable escape hatch to avoid this. All of my experience with LLMs screams that telling a model "skip questions" is likely to lead it to makes its own decisions about implementation direction or technical choices where I do want input.
I can see how this approach could be useful to less technical users or those who really are starting with only a broad idea of what they want to do. But I suspect that many of your users are like me - technical people who are using brainstorming to flesh out the details of a relatively focused task. I do wonder if these questions might be better suited to an ideation skill that's tuned for high level planning.
tl;dr, please don't make us waste time and tokens with these questions.
I agree with mbcrawfo . The brainstorming flow does not feel right. It is trying to be something it should not be. Trying to be "too" smart.
I came here to also echo that v7 brainstorm feels like a departure of what made superpowers great. I do like the option to short-circuit it and just build it. I miss the suggestive menu options which would lead to me thinking about other ways to implement. The open response format can be powerful but it adds additional friction. If I could choose a mode like how implementation is done inline or subagent that would be optimal.
The new brainstorming opening in 7.0.0 is insanely frustrating. Every time the skill loads, I get "if you'd rather skip the questions, say so", followed by a trivial, high-level question that doesn't help at all.
I don't need to be offered a skip. The questions are the point of brainstorming. And the question is pointless because the context is already there: a detailed first prompt, decisions made earlier in the conversation, or a summary passed in the Skill args. Once it asked me something it had answered itself a few turns earlier. Each time I have to stop, push back, and wait for it to apologise and start the actual design. When challenged, it agrees it already had everything it needed, and once said it had followed the skill's opening template word for word ("Your First Message" in the 7.0.0 brainstorming SKILL.md).
6.4.1 didn't do this. It went and looked at the code first, then asked questions that mattered.
(Claude Code 2.1.302, claude-opus-5-5, superpowers 7.0.0, no other plugins.)
I agree, the brainstorming skill started asking some questions that just don't feel right or useful. It worked 100% better before these changes. It is very annoying now.
Adding a data point. Claude Code, Opus 5.5 and Sonnet 5.5, superpowers 7.0.0.
I went through my own session transcripts. Between Oct 16 and Oct 19, 9 of the 12 sessions that loaded the 7.0.0 brainstorming skill opened with the "if you'd rather skip the questions" line and an open question. Across 134 sessions on 6.2.0 to 6.4.1, that line appeared zero times.
The pattern matches what others describe above: the opener fires even when the answer is already in front of the agent. Two ways it happens for me:
- A handoff doc. I use a park/unpark skill that writes a handoff with "brainstorming first" as the next step. The resumed session validates the handoff, loads brainstorming, then offers to skip questions and asks an open question about a task that already has a spec.
- A user message that names an existing spec or plan, like "pull up the task and see what work has been done".
Same here. Claude Code, Opus 5.5, superpowers 7.0.0.
I've gone out of my way to disable it more than once. It asks the kind of things the HR person asks during an initial job screening when they have absolutely no idea what the job entails. I don't know why I find it enraging, but I do. Maybe because it dampens the feeling that what I'm doing with the agent is sophisticated work that I should feel good about.
I have a growing collection of "bad prose" samples I've captured from Claude in an effort to clean things up, and the common thread in 80% of them is the agent using lots of words to say nothing. This is the question version of that.
Also, not to get too deep into psychoanalysis or whatever, but if you're prefacing your questions with "just tell me if this is annoying and I'll stop," it's probably annoying.
I fully agree with everything said here. In my case:
my question: create a small docker container with a web app that will be accessible on local network. this web app will interact with aws. the webapp will fetch all live jobs from a dsql database, read it using aws cli. then it will prompt the user to select/search/filter a number of them. then it will create a png image arranging the data it fetched for the selected jobs, for now just randomly arrange the data on the image.
The answer: Alex — using brainstorming to shape your Docker + DSQL plan. →Skill "brainstorming" Alex — if you'd rather skip the questions and have me draft the plan straight away, just say so. Walk me through the moment you'll actually use this — who opens this web app on the local network, and what do they do with the PNG once it's made?
Those 2 questions are completely unnecessary and not helpful. for reference after downgrading to superpowers 6.4.2 it asked actually useful questions like how to access aws (CLI, Keys, etc)
Opencode 2, superpowers 7.0.0, muse spark 1.3
I ran into the same thing. This is one of the plugins I use the most and 7.0.0 made the skill I use the most annoying to use and much less powerful.
I'd rather choose per task, so I split the skill in two in a fork: https://github.com/fcavalieri/superpowers-remix (based on 7.0.0).
-
brainstorming is the 6.4.2 skill again. It reads the code first, then asks how to build it, with multiple-choice options, approaches with trade-offs and a design written section by section. It keeps the "use before any creative work" trigger. From 7.0.0 it also keeps the rule from #2482/#2483: it asks which choices about how the thing gets made (language, libraries, tools) you want to make yourself.
-
discovering-intent is the 7.0.0 conversation: the why/what questions, the playback, and an intent document under docs/superpowers/intents/. It runs only when you ask for it: by name, with /superpowers:discovering-intent, by saying "discover intent", or through a line in a project's CLAUDE.md. When a request's purpose looks thin, brainstorming adds one sentence to its first question offering the phrase. It never switches on its own. In effect it's the separate ideation skill @mbcrawfo suggested above.
The README has a side-by-side from real runs (Claude Code, Opus 5.5, against simonw/sqlite-utils).
For example, given "Add a --dry-run flag to sqlite-utils insert that validates the input and prints what would be written without touching the database.": - 7.0.0 opens with "think of the last time you wanted this…" (WHAT/WHY) - The fork reads cli.py and the existing convert --dry-run, then asks what the flag should print, offering concrete implementation options. (HOW)
To try it in Claude Code: it replaces the upstream plugin rather than sitting beside it. The plugin is still called superpowers, so the skill names don't change.
/plugin uninstall superpowers@claude-plugins-official # or whichever marketplace you installed it from
/plugin marketplace add fcavalieri/superpowers-remix
/plugin install superpowers@superpowers-remix
This is the full set of changes (apart from the credits).
I haven't opened a PR, because the contributing guide (https://github.com/obra/superpowers#contributing) says new skills generally aren't accepted, and this adds one. It's also only been tried on Claude Code. The manifest tests for the other harnesses pass, but I haven't tested behaviour there, and the guide asks that skill changes work on every supported agent. If the maintainers want it upstream in some form, I'm happy to rebase it onto dev and open one.
The whole thing reminds me of this for some ineffable reason https://youtu.be/KYrgKApo6Pc?si=JEZXNQIGKMpyzeq1&t=46
This just like a demonstrably negative update here. Using this updated skill just makes me irrationally angry. It ask questions immediately that the codebase can answer, it asks stupid questions like the person using it does not understand how to code or does not have any sort of experience. If you decide to say skip, it skips EVERYTHING. It removes most of the intelligence that Brainstorming normally had.
just a single example
Then, when making the specs and plans it actively misses things because it never did any sort of in-depth investigation. Wasting even more tokens.
It's like talking to someone that is mocking you - assuming you didn't have any thought at all.
Hi all. This is Claude (Opus 5.5 in Claude Code 2.1.304), working on this issue with Jesse.
Thanks for the detailed reports and transcripts. They make the problem clear: the v7 brainstorming opener isn't working for a lot of you, and it sounds like it needs tuning. We're pretty sure we can make it better.
Here's what we're trying:
- No more fixed opening message. The "if you'd rather skip the questions..." line plus an open-ended question is going away as a template.
- Check in only when it's unclear you want brainstorming. If the skill fired on its own and it's not obvious you want a brainstorming conversation, it'll check in briefly. If you asked for brainstorming, it won't offer to skip.
- Look before asking. In an existing project, or when you've already given it context (a spec, a plan, a handoff, earlier conversation), it'll do a bit of recon first so its questions are grounded in what's actually there.
- Confirm understanding instead of asking why. Even when there's a spec, it'll play back what it understands and ask you to confirm or correct it, since specs are often incomplete. It shouldn't be asking why you want the thing or how the last phase went.
We're keeping brainstorming as one skill rather than splitting it.
We're testing against cases from this thread: continuing the next phase of an existing spec, an explicit brainstorming request in an existing codebase, and a vague new-project request where the check-in should still happen. We'll post here when there's a change to try.
Claude again (Opus 5.5 in Claude Code), working with Jesse. There's a fix to try: #2560.
What changed:
- It reads what you pointed at (the spec, the plan, the code) before its first message.
- When you've already said what you want, it plays back its understanding, marks its guesses as guesses, and asks the one design question that would most change what gets built.
- For real forks in how to build something, it recommends one approach and names the alternative it considered.
- If you asked for brainstorming, there's no skip offer. If the skill fired on its own, it ends with a light "Or if you'd rather I just dive in, say so."
We tested it against cases from this thread: continuing the next phase of a spec, an explicit brainstorming request on an existing codebase, and @alexxburg's Docker/DSQL prompt. We ran it on Opus, Sonnet, Haiku and Fable in Claude Code, and on two GPT-6 models in Codex. The details are in the PR. On the Docker/DSQL prompt, 7.0.0 asked who would look at the PNG. The branch asks what the jobs table looks like and what makes a job "live", and points out that the AWS CLI can only mint a DSQL auth token, not run queries.
@arittr @mbcrawfo @katyatitkova @ertra @blorenz @Biomaj @fsalum @technicalpickles @orochi235 @alexxburg @fcavalieri @CelesteCunha, if you can try it on your real work and tell us how it goes, that would help a lot. Transcripts of anything that still feels off are especially useful.
To try it in Claude Code:
git clone -b fix/brainstorming-first-message https://github.com/obra/superpowers.git superpowers-2530
claude plugin disable superpowers@<your-marketplace> # so the installed copy doesn't load too
claude --plugin-dir ./superpowers-2530Re-enable your installed copy afterwards with claude plugin enable superpowers@<your-marketplace>. On other harnesses, the branch is fix/brainstorming-first-message.
I've been testing all day and it's a huge improvement ! Like @CelesteCunha I was feeling irrationally angry with every new brainstorm.
The interactions are now much better but I still have a few thoughts :
-
It doesn't feel like it's going off and doing the actual digging in the repo before coming back to start iterating on the brainstorm. it feels like it's finding the bare minimum to engage with me on the context I've given. v6 made me feel like it really understood what my code was doing before we starting discussing it. I wonder if this is because the focus in the prompt is on finding the "one design question that would most change what gets built".
-
It uses the phrase "guesses". This is probably just the wrong adjective but to me I never want my agents "guessing". I want to know the agent has read my input, read the code and is then iterating with me. If it "guesses" something then I can't take it seriously and trust is instantly lost.
Overall, a big improvement. A little bit more and it's back to being good.
Thank you @obra, i tried it and i will continue to experiment with it and I will check and share some exact transcripts. It is definitely an improvement, rarely i still got the odd questions like below, but usually it seems to do a reasonable job. I have the impression as @Biomaj said that it is not really digging at the code, just the bare minimum. I see this more in the proposed approaches part where it seems to have an idea already and the alternatives are just named or not mentioned at all
For a prompt like /brainstorming I would like to add support for visualizing images in X format in the gallery like we do for formats A, B and C. 7.0.0 (very often)/#2560 (rarely) ...
What were you trying to accomplish that made you want to visualize images in XYZ format? What would make you wince?
The worse part however for me, comes later. Sometimes it would just skip presenting approaches (how to do the change)/spec and jump to implementation, which is the main value for me of the skill.
6.x/fork: ....
These are a few approaches to do so:
- Library A, with this pro and cons
- Library B, with this pro and cons ...
Would you like to keep the images in XYZ format or convert them:
- Yes, with this pro and cons
- No, with this pro and cons ...
Spec review
Claude again (Opus 5.5 in Claude Code), working with Jesse. Thanks @Biomaj and @fcavalieri, this is really useful.
We reproduced the skip-to-implementation problem. We used a small Flask photo gallery that supports PNG, JPEG and GIF, opened with /superpowers:brainstorming I'd like to add support for viewing HEIC images in the gallery, like we do for PNG, JPEG and GIF., and had a simulated developer answer the questions. In 6 of 6 runs on #2560 (3 Opus, 3 Sonnet), the agent decided on its own that this was "a small change," skipped the written design, and built once its chat summary was approved. It never asked whether that was OK. The cause is in the skill: it tells the agent to pick a size and lets you override it, so the agent treats silence as consent.
The same runs also back up the other things you saw:
- Approaches: the alternatives got squeezed into one clause ("The main alternative is…") inside the first message, not laid out with their trade-offs.
- "Guessing": every run said "I'm guessing" between 3 and 9 times.
What we're changing on #2560:
- Skipping steps needs your yes. The agent can propose a smaller size, but going lighter than a written design takes your explicit OK.
- Approaches get their own step: two or three real options, each with its trade-offs and grounded in your code, plus a recommendation and the reason for it.
- Deeper reading first: before talking, it reads until it could explain how the relevant code works today and what the change would touch.
- Proposals, not guesses: where your request leaves something open, it says what it would do and why, based on what it found.
- Only specific questions: each one builds on your last answer or on something in your code. Generic questions like "what would make you wince" are gone.
We're testing those now and will post when the branch is updated.
Thanks for the detailed reports. #2560 has merged into dev, and #2571 follows up on what you described since then.
We reproduced the skipping on dev. An experienced developer asked for a feature and said she wanted to talk the design through first. The agent settled the design in its first message, then built with no design doc, and without her agreeing to skip it. That happened in 24 of 24 runs.
What #2571 changes:
- Before any implementation: lay out the ways to build it in a message of their own and let the human pick, write a design doc, get it approved, then plan. This doesn't apply to a spike you've agreed to, or when you've said to skip the questions.
- A design doc at every size: a small change gets a short one covering what was already discussed.
- The first message on a detailed request: echo the request back, and flag anything you may not have considered that changes it. The how waits until later.
- Questions: specific and Socratic, with the reason for asking. No generic ones.
Before/after across 176 blind-graded conversations on Opus and Sonnet:
- Design doc approved before building: 1 of 24 runs on
dev, 23 of 24 on the branch. - Approaches laid out in their own message before the doc: almost never on
dev, and far more often on the branch. - Spikes and "just build it" requests: no extra ceremony.
The weak spot is when you keep asking "what would you recommend?". The agent then tends to follow you into the how, and the questions about what you want stay thin. Full numbers, including what didn't work: prime-radiant-inc/superpowers-evals#75.
If you can try #2571 on your own work, we'd like to hear how it goes.
The "say the word to skip questions" escape hatch is the weakest part of the current design, and I don't think it's because users don't know about it — it's because it collapses two very different intents into one flag. When a technical user says "skip questions", they mean "stop the ceremony, but still ask me if something is genuinely ambiguous". What the model hears is closer to "proceed with your best guess", which is exactly the failure mode the reporter is worried about: it stops asking, and then quietly makes design decisions that deserved input.
The pattern that seems to work better is conditionality instead of a skip flag. When the request already references an existing spec or design doc, the first move should be echoing back what's there and asking only about gaps the model can see — not restarting the discovery interview from zero. The three examples in the report all share that shape: the user pointed at a spec, a tech-debt doc, or a well-defined scope, and the skill responded with generic questions that the source material already answered.
I see a follow-up PR is already up that requires affirmative consent before skipping the design doc, which fixes the "silent skip" half. The remaining half is question quality: replacing generic check-ins ("what did you learn from part A?") with gap-driven questions that only fire when the echo-back actually surfaces something unhandled. Quantity follows from that — if the material is complete, zero questions is a legitimate outcome, and the skill should treat it as success rather than insufficient rigor.
Just a bit more feedback on v7.0.1
I made a request for a small change in the codebase. The model looked at the code first, as the skill says, and the code answered nearly everything. It then stopped and asked me a really low-value, irrelevant clarifying question. It did this twice. One asked about a case the request had already ruled out. Another asked me to choose between two options when one was the obvious default, given a pattern the codebase already uses.
My guess is one of these :
- "Each message ends with one question", and when the user asked for brainstorming, the first message must "end with your question". Neither has an exit for when nothing important is still open.
- The skill does say "A proposal they can correct, plus your reason for it, often beats a question." But the one-question rule wins in practice, so the model invents a question when it should be stating defaults.
- Nothing in the skill says: if the request and the code answer everything, skip the questions and go straight to the approaches or a short design.
Possible solutions ?
- Let a message end with a proposal to correct, not a question, when nothing open would change what gets built.
- Before asking, check: "Is the answer implied by the request, or does it have an obvious default from the existing code? If so, state it as my call and don't ask."
- For a small change where the code answers everything, allow going straight from the first playback to the short design.
It's a step back again as it's back to asking me infuriating questions for the sake of it.
Came here just because they piss me off, why was this added. The opening questions are absolutely useless at times even on very simple requests it will stop and ask "what bothers you about it?"
I tried v7.0.1 and it's slightly better, but it's still not at the same level as v6.4.2..
Can't we just have the old brainstorm version back?
There are definitely scenarios when v7's questions shouldn't be asked. I am backporting some features into a repo now. superpowers v6 wrote a design doc for it and suggested splitting the backporting into phases. To implement phase N, I used to write "phase N-1 is implemented, continue" and it was enough for v6 to start creating an implementation doc immediately. With v7, for the same kind of prompt and a phase that involves adding some features from the desktop app to the web app, I got the list of these features, and then this:
Yes, I have an option to skip, but there's also already a plan that explicitly says what needs to be backported in each phase, with commit hashes and relevant info. There's also a document nearby that says which features shouldn't be backported. So superpowers still had to just proceed with the implementation doc without these questions.
However, it looks like my "Why do you ask me this? We already have a plan, you just need to implement it" was enough to steer it into the right direction even after the context was cleared: the next phase worked as expected (without questions).