Are Superpowers or GSD Better Than OpenSpec?
After a rather disappointing experience with OpenSpec I kept looking further and found Superpowers and Get Shit Done (GSD) as candidates for another round of tests. I tried to build the same application as with OpenSpec and found some interesting differences.
Superpowers
We install Superpowers as a plugin in Claude Code, what I like much more than the installation of a Node.js package. The command is nicely documented in the GitHub Readme file and lets you do the installation even if you are new to the plugin system of Claude Code.
To access Superpowers, we do not need a specific command or prefix. We just tell that we want to brainstorm an application and Claude starts using the skills of Superpowers. That is less intuitive than an explicit command, but it works. The questions Superpowers asks are thoughtful and take us quickly at a point in which we have a detailed plan. The plan covers the file structure, the packages, basic classes and much, much more – too much to thoroughly review everything.
We also get a nice action plan that allows Superpowers to do some work in parallel. If everything is ready, we can kick off the implementation and Claude starts working. And working and working until all the tokens for the session are gone. Unlike OpenSpec, I run out of tokens before I even had something I could start. After waiting on the reset, I could continue with the work and got something I could start right before the second session run out of tokens.
The application I had after two full sessions crashed when the user enters anything wrong in any of the many form fields. I had higher expectations, especially after that many fixes it applied. I could see these changes because Superpowers did commits after every step and I had a chance to see what changed.
The overall experience was better than OpenSpec, but not so good that I would like to invest more time. Let us jump to the next tool.
Get Shit Done (GSD)
GSD was created as a lightweight alternative to process-heavy tools like BMAD or Speckit. However, compared to OpenSpec and Superpowers it looked like a more heavy-weighted process.
We can install GSD through npx with this command:
This gives us a dialog in which we select for what AI tool we want to install it and where. We already get the first important distinction between GSD and the other tools: dialogs. Dialogs are widely used in GSD, and we can fill them out in the command line.
To start with our greenfield project, we can enter /gsd:new-project and GSD takes over with the first and most important question: What do you want to build?
We can now start describing what we want to build, and GSD asks questions to clarify our requirements. It then goes on and does research on the stack, the features we specified, the architecture and pitfalls. All it finds ends up as Markdown files inside the .planning folder, what we can check to see if we are still on course. We get a few additional questions, more checks if the requirements are what we want and then we can define the priority. Do we want this requirement as part of version 1 or do we want to delay it to version 2? With all that set, the implementation starts.
If you are too eager and run /clear too fast, you find yourself in an annoying trap, then the screen gets cleared as well. Should this happen to you, these are the next commands to use:
GSD splits the work in phases and at the end of each phase we can check it for ourselves and manually approve the work. That way we see early on when something is totally off. The first phase in my demo application was the authentication and user management, that I could check and after minor corrections approve.
We then continue with the next phase, where we again can discuss details before we plan the detailed tasks. Only after this step do we let Claude implement the code. This gives us much more detailed control, what may not fit the workflow of everyone.
GSD burns through tokens as if there is no tomorrow. It took me 3 full sessions to get at the same feature set that took OpenSpec only one session. However, with GSD I got an application that worked, it followed my instructions and only needed a few minor adjustments in the layout to be useful.
Comparing the 3 tools
OpenSpec, Superpowers and GSD offer a full software development cycle. How they do it differs, and so do the results.
OpenSpec has the big trap right at the start where we need to work differently in a greenfield project than when we have code around. If we try it the same way, OpenSpec runs in the wrong direction at nearly unmatched speed. But the wrong direction does not help. It is fixable and when we know what we do, we can get what we want. In my case the application it created was full of problems, the tests were marked to skip and the whole safety net of the process it claimed to follow fell apart. On the plus side, it used relatively few resources to produce this non-functioning application.
Superpowers had a much better user experience, especially for first-time users. It started with an extensive planning phase, which collected a lot more information than OpenSpec. It fell apart in the endless reworking of 2 implementation steps that burned through a large amount of tokens. Despite the longer time and the many fixes it did on its own, the application crashed at the first form field that missed data.
GSD is using massively more resources, but at the end I got an application that did what I asked for. The many more questions I had to answer made sure that GSD could build the right tool. With the dialog-based approach I could choose between options, prioritise features and add more details to the points I found important.
All three tools showed that the standard plan for teams in Claude Code is not enough. If you want to do more than the most basic little feature, you need to upgrade to the premium seat, that currently costs 100$/month. With the larger session you can get more work done and do not constantly run out of resources.
Next
My little test application for travel destinations was a good exercise to compare 3 tools for spec-driven development with Claude Code. After this experiment I will spend more time with GSD, then that was the only tool that delivered an application I had not to fix. But all 3 tools showed a common problem: They do so much that it is impossible to keep track. Next week we explore 2 ways to keep an eye on what is going on.