OpenSpec vs Spec Kit vs SuperPowers: Stop Shopping for the Right SDD Tool

A builder on r/SpecDrivenDevelopment recently laid out, carefully and honestly, the difference between SuperPowers, OpenSpec, and Spec Kit. He had clearly done the homework. He could tell you that SuperPowers keeps timestamped specs that accumulate, that OpenSpec merges everything into a single spec artifact, that Spec Kit scaffolds the whole flow. And then he ended with the most honest line in the entire thread:

"I think we are all still figuring these things out. Sometimes it's best to just dive in and give it a try."

That sentence is the real story of spec-driven development right now. Not which tool wins. The fact that thoughtful, motivated builders are spending their evenings comparing CLIs instead of shipping features, because the tooling layer is moving faster than anyone can keep up with. The shopping has become the work.

Here is the hypothesis worth testing: the tool you pick for spec-driven development matters far less than you think, and the time you spend choosing is mostly wasted, because the practice underneath every one of these tools is identical and that practice is the only durable part.

#The Tools Genuinely Differ (and It Mostly Doesn't Matter)

Let's be fair to the tools first, because they are real and they are good.

OpenSpec is a lightweight, open-source framework that crossed 27,000 GitHub stars in under six months. Its whole pitch is a minimal three-step loop: propose, apply, archive. Specs live as markdown in your repo, no API keys, no MCP required. Thoughtworks' Technology Radar praised exactly that minimalism: "fluid, minimal workflow."

GitHub Spec Kit is the scaffolding-heavy option. It gives you a structured set of commands and templates that walk you from a specification through a plan to tasks, often generating acceptance criteria in EARS syntax. It is opinionated about the phases.

SuperPowers takes yet another stance: specs are timestamped and accumulate over time, so you get a running history of intent rather than one merged document.

Those are real differences. If you are the kind of person who enjoys this, you can spend a happy weekend comparing them. But notice what you are actually comparing. You are comparing how each tool stores and sequences the same four things: a description of what you want, a plan for building it, criteria for knowing it's done, and a record of decisions. The storage format is the variable. The four things are the constant.

This is the reframe. The spec-driven tools are not competing on whether you should write a spec. They all agree on that completely. They are competing on file layout.

#What Actually Survives

Here is where it gets uncomfortable for anyone deep in tool comparison.

Look at how fast this layer is churning. Latent.Space recently catalogued what they called "meta-harness summer": Conductor, Zed's ACP, Vercel's Eve, HarnessAgent, Databricks' Omnigent, a new orchestration layer landing seemingly every week. The SDD tools sit one layer down and they are churning just as fast. The tool you carefully chose this month may be unmaintained by spring, or eclipsed by something that didn't exist when you started reading the comparison threads.

So what survives the churn?

Not the tool. The spec.

A requirement that says what you're building and why. The acceptance criteria that define done. The record of decisions that explains, six months from now, why the code is the way it is. Those artifacts are plain text. They outlive any CLI that produced them. You could move them from OpenSpec to Spec Kit to a text file to a different tool entirely, and they would lose nothing, because they were never really about the tool.

Boris Cherny, who reports writing 100% of his Claude Code contributions with Claude Code, describes his job now as writing loops and making sure they can verify themselves. The loop is what he owns. The model is rented. The same logic applies one level up: the spec is what you own, the tool is rented.

Once you see it that way, the comparison shopping looks different. You weren't choosing a methodology. You were choosing a temporary container for the thing that actually matters.

#The Practice Underneath All Three

Strip away OpenSpec, Spec Kit, and SuperPowers entirely, and here is the practice every one of them is trying to encode. It comes down to three habits.

One spec per feature. Not a 40-page document for the whole product, and not a one-line prompt. A focused description of a single buildable thing, scoped tightly enough that an agent can build it and you can check it.

A plan you can review before the agent writes code. The point of planning first is not bureaucracy. It is that catching a wrong assumption in a paragraph costs minutes, and catching it in a generated codebase costs an afternoon. The plan is where you find the questions you didn't think to ask.

Criteria that accumulate. Each feature's acceptance criteria become part of a growing record of what your product is supposed to do. That record is what lets you change things later without breaking what already worked, and it is what tells you, definitively, whether a feature is done or just looks done.

That's it. That is the whole of spec-driven development, and it is tool-agnostic by definition. The r/SpecDrivenDevelopment poster had actually already figured this out, almost word for word. He described the shared model as "one spec per feature, one plan per spec." He just couldn't tell that he'd found the answer, because the tool comparison was still demanding his attention.

Consider the difference concretely.

Tool-first thinking: "Should I use OpenSpec or Spec Kit? OpenSpec is lighter but Spec Kit has better task templates, though SuperPowers' accumulation model fits how I work, but the community around OpenSpec is bigger right now."

Practice-first thinking: "This feature is 'let users reset their password by email.' Here's what done looks like: a logged-out user requests a reset, gets a one-time link valid for an hour, sets a new password, and the old one stops working. Now which tool helps me build that against those criteria?"

The second builder is going to ship. The first one is going to keep reading comparison threads.

#Where BrainGrid Sits

This is the gap BrainGrid is built to close, and it's worth being precise about how.

The SDD tools hand you a framework and leave you to run it. You install the CLI, learn its commands, wire it into your agent, and remember to follow the steps every time. The practice is sound, but you are assembling and maintaining it yourself, which is exactly the labor the r/SpecDrivenDevelopment thread is full of. (If you want a deeper look at one tool's tradeoffs, we compared Kiro and BrainGrid's takes on spec-driven development and where each fits.)

BrainGrid ships the practice as a product instead of a framework. You describe a feature, and the Planning Agent turns it into a requirement with acceptance criteria, data models, and designs, challenging the vague parts and asking the questions you didn't think of before any code is written. That is "one spec per feature, one plan per spec," done for you rather than configured by you. Then the Builder Agent builds it, two ways: in BrainGrid Cloud, a sandbox with live preview that opens a pull request, or on your own computer in your GitHub repo with Claude Code, Cursor, or Codex over MCP. Whichever agent you point at it, the plan and the criteria are the same. Every feature flows across a board from planning to building to published, and the specs, decisions, and verifications accumulate into a record of the product. Swap the agent, swap the model, keep the workflow.

The structural point is the same one the tools are trying to deliver, just without the assembly: the spec is the durable asset, and a feature isn't done until the evidence says it matches what you intended. You don't pick a file format and hope you maintain the discipline. The discipline is the product.

#The Honest Trade-Off

There is a real cost here, and it cuts against BrainGrid as much as it favors it.

If you love your tools, an open-source framework like OpenSpec gives you total control over every file and every step. You own the whole stack. Some builders genuinely want that, and for them the comparison shopping is not waste, it's craft. A managed product trades that control for the thing being done for you. That is a real choice, and it's not the right one for everyone.

But for most builders, and certainly for the ones writing "we are all still figuring these things out," the control isn't the point. Shipping is the point. (If you're specifically weighing the open-source frameworks, our BrainGrid vs Spec Kit comparison walks the tradeoff in detail.) And the truth the tool-comparison threads obscure is that you can start practicing spec-driven development today, in any tool, the moment you write one tight spec with real acceptance criteria for the next feature you build. You do not need to finish the research first.

#FAQ

#What is OpenSpec?

OpenSpec is a lightweight, open-source spec-driven development framework for AI coding agents. It stores specifications as markdown in your repo and runs a minimal three-step loop, propose, apply, archive, with no API keys or MCP required. It is one of several tools (alongside GitHub Spec Kit and SuperPowers) that help you write a spec before your coding agent writes code. The framework differs from the others mainly in how it stores and sequences specs, not in the underlying practice.

#What is the difference between OpenSpec and Spec Kit?

OpenSpec is minimal and merges work into a single evolving spec artifact through a propose-apply-archive loop. GitHub Spec Kit is more scaffolding-heavy, giving you structured commands and templates that walk you from a specification through a plan to tasks, often in EARS syntax. The practical difference is file layout and how opinionated each is about the phases. Both encode the same core practice: one spec per feature, a reviewable plan, and acceptance criteria that define done.

#Which spec-driven development tool is best?

There is no single best tool, and the choice matters less than most comparison threads suggest. OpenSpec, Spec Kit, and SuperPowers all encode the same practice and differ mainly in how they store and sequence specs. The better question is whether you are actually practicing spec-driven development: writing one focused spec per feature, reviewing a plan before the agent codes, and keeping acceptance criteria that accumulate. Any of the tools can support that. So can a managed product like BrainGrid, which ships the practice rather than a framework you assemble.

#Do I need a tool to do spec-driven development?

No. Spec-driven development is a practice, not a tool. You can start today by writing one tight spec for your next feature, including specific acceptance criteria for what "done" means, then building against it and checking the result. The tools (OpenSpec, Spec Kit, SuperPowers) automate and structure that habit, and a product like BrainGrid runs the whole loop for you, but the practice itself works in a plain markdown file. The durable asset is the spec, not the software that produced it.

#Why does spec-driven development matter for AI coding agents?

Because a vague prompt is a confident mistake machine. When an agent writes most of the code, the bottleneck stops being typing speed and becomes clarity: how precisely you describe what you want and how done is defined. A spec gives the agent a target and gives you a way to verify the result against acceptance criteria instead of reading every line. As agents get more autonomous, this matters more, not less, because more autonomy means more decisions nobody wrote down unless the spec captured them.

BrainGrid is the plan-first app-building platform that ships the spec-driven practice as a product: it plans each feature into acceptance criteria, builds with your choice of agent, and verifies every change with evidence, so you stop shopping for tools and start shipping. Try it at braingrid.ai.