April 02, 2026
I have no connection to the authors of the Superpowers plugin for Cloud Code, but I keep talking about it to everyone I talk to. Using cloud code with superpowers is much more productive and the features built by it are much more perfect than stock cloud code. I can not recommend it enough.
Before, my main issue with Cloud Code (and other models + harnesses I’ve tried) was that sometimes it was too early to jump into implementing a solution that might be perfect, or off the table altogether.
Plan mode helped a bit. However, in planning mode, the cloud will write a huge planning document and ask for feedback. It is difficult to review a multi-page plan. To make matters worse, if you give it feedback, it will respond with an entirely new version of the multi-page plan. This is not a productive way to plan a project or feature.
Superpowers fixes both of these issues and more. I’ll present the workflow as I understand it, and why I appreciate its structure, but you can also stop reading here and try it out.
The high-level flow of superpowers is: Brainstorming → Reviewing options and tradeoffs → Planning sketch → Design document → Implementation plan → Implementation phase.
brainstorming
Superpowers almost always start in brainstorming mode. It examines your codebase, asks you a lot of questions, and gives some general guidelines you can go by.
Options and Tradeoffs
An important part of the brainstorming process is that, after asking the questions, it will present several options with tradeoffs. It is extremely useful to consider different options, see the tradeoffs identified, and discuss or select them before getting more detailed information.
Recently, they also added a visual design skill that enables Cloud to create simple mock-ups for UI changes and other visual features. This starts a local dev server so you can review, discuss, and iterate the mock-up before moving forward. Great work team, keep up the great work.
plan drawing
After you’ve agreed on options to pursue, Cloud + Superpowers will give you a high-level description of the plan. This could be a dozen bullet points or a slightly longer article. Unlike the default planning mode, this is a much easier format to use.
design document
Only after a high-level version of the plan is agreed upon, Cloud + Superpowers will write a full design document. It’s similar to the kind of plan one would use to write cloud code without superpowers. But at this point, you’ve already agreed upon high-level direction, making it much easier to review and comment on the plan. If you have comments, they’ll probably be a little more detailed than just “rewrite this whole thing and go in a different direction”.
Additionally, SuperPower’s plan document is a Markdown file in your repository that you can read, comment on, and edit in your editor. A friend said that being able to edit the plan on one’s own terms felt far more empowering than Cloud Code’s usual UX for reviewing plans.
Implementation Planning and Implementation
After you approve the design document, Cloud + Superpowers will write an implementation plan and review that plan against the design document. Once you approve it, it can launch sub-agents to implement each part of the plan, and it automatically reviews their work against the implementation plan.
Thank you
Thanks to Jesse Vincent for creating this plugin! This has made my use of Cloud Code much more productive. I feel better about the tradeoffs and am more confident that the code written does what I want.
I’ll eagerly install each Superpowers update and keep an eye on what else Jesse’s company Prime Radiant puts out (you can even add his blog to your scour feed 😉).
Superpowers for other domains?
I have friends who are academic researchers. Every time they tell me about the problems they have using the cloud or other AI tools, I’ve immediately thought they could use an equivalent structured workflow plugin that adapts superpower-style workflows to non-programming domains. Just a thought for the Prime Radiant folks or others who are building agent-centric development tools.
Thanks also to Alex Kesselring and Eliot Hederman for comments on a draft of this blog post.
<a href