OpenSpec vs. Superpowers vs. pi-sdd-kit: SDD Tools Compared

Every time I post about my own spec-driven setup, the same question comes back: how does this compare to OpenSpec? To Superpowers? Is it not just AGENTS.md with extra steps? Fair questions, and they deserve a straight answer instead of a pitch.

I am going to answer them from production, not from a feature matrix. I shipped a 13-app crypto fintech in 70 days, solo, with AI agents moving real money. What decided which tool I could trust was never the feature list. It was one question: when the agent hands me a draft that looks done, is it allowed to run? Because the draft that looks done is the one that cost me the most.

So here is the honest map. Four ways to give an AI agent the intent it does not have on its own, sorted by how much process each one forces on you. I ship one of them (pi-sdd-kit), and I will tell you plainly where it is the wrong choice.

If you are new to the method itself, start with What Is Spec-Driven Development?. This piece assumes you already buy the why, and you are choosing the tool.

They all solve one problem

An AI agent operates in an eternal present. Every session starts from nothing. It has no memory of the constraint you added at 10pm, the edge case you decided was out of scope, the reason you picked Postgres over SQLite. So it reinvents those decisions, differently, on every run. And left alone, it races straight to code before you have agreed on what the code should do.

You feel this as the confident draft. You describe the feature, the agent writes sixty lines, the demo runs, the terminal is green. It looks done. Then production finds what the draft left out: the timeout you never named, the retry that bills the customer twice, the record written half way. The agent wrote the happy path. Everything that only shows up when the code meets something real got skipped, quietly, and it kept a straight face while doing it.

That is the whole problem. A defect in AI-generated code is not a bug in the code. It is a gap in the intent you never wrote down. I covered the mechanism in Spec-Driven Development vs. Vibe Coding. Every tool below is an answer to the same question: where does the intent live, and how much are you forced to write it down before the agent runs?

The gap is not anecdotal anymore

+98%

more pull requests with AI2025 DORA report

+243%

more incidents per pull requestthe throughput did not come free

31%

more PRs merged with zero human reviewconfident output, no second look

The tools differ on one axis more than any other: how much process they impose. From none to a lot. That is the spectrum.

1. Plain memory: AGENTS.md and nothing else

The zero-install option. You keep two to four small markdown files in the repo (AGENTS.md, or CLAUDE.md, a conventions.md, a decisions.md) with the durable rules, the stack, and the choices that must not drift. Every session, the agent reads them. You update them by hand.

This is more than most people give it credit for. A commenter on one of my posts described exactly this: 2 to 3 short docs per project, a hard 5kb cap so they never blow the context window, edited down by hand after each big task. On a codebase under 5000 lines where you refactor aggressively, that is genuinely enough. Do not add a tool to it.

Where it breaks: there is no enforcement. The docs are memory, not a workflow. Nothing stops the agent from reading a plausible-looking file and coding the wrong thing. There is no per-feature spec, no gate, no structure for “here is what this specific change should do.” It is a great floor. It is not a method.

2. OpenSpec: a lightweight spec layer, deliberately fluid

OpenSpec (@fission-ai/openspec, MIT) calls itself the most loved spec framework, and it earns the tagline. It adds a thin spec layer on top of any agent. You install it globally, run openspec init, and then talk to your assistant through slash commands: /opsx:explore to think an idea through, /opsx:propose to turn it into a change, /opsx:apply to implement, /opsx:archive to fold the result back into the specs.

The mental model is two folders. openspec/specs/ is the current source of truth. openspec/changes/<name>/ is a proposed change, each one its own folder holding a proposal.md, specs/, design.md, and tasks.md. You agree on the change, the agent implements it, then it archives and the specs absorb what shipped.

The defining choice is right in their docs: “update any artifact anytime, no rigid phase gates.” OpenSpec is intentionally fluid. It is built for brownfield, works with 25-plus assistants, and it does not make you stop and formally sign off at each stage. That is a feature. It is also the exact thing that separates it from what I built.

Where it fits: you want spec-as-source-of-truth and clean change proposals, across whatever agent you happen to use, without ceremony. Where it might not: if “no rigid phase gates” is precisely the discipline you were hoping the tool would enforce, OpenSpec deliberately does not.

3. Superpowers: a whole methodology, not a spec tool

Superpowers (Jesse Vincent, MIT, north of 250k stars) is a different animal. It is not a spec framework. It is a complete software development methodology built as a library of composable skills that trigger automatically, plus the instructions to make the agent actually use them.

Its workflow runs the full lifecycle: brainstorming (Socratic design, shown in readable chunks for sign-off), using-git-worktrees, writing-plans (bite-sized tasks with exact file paths), subagent-driven-development (a fresh subagent per task with two-stage review), test-driven-development (real RED-GREEN-REFACTOR, it deletes code written before a test), requesting-code-review, and finishing-a-development-branch. It runs across Claude Code, Codex, Cursor, Kimi, OpenCode, and Pi, among others. The skills are mandatory workflows, not suggestions, and the agent can run autonomously for a couple of hours without leaving the plan.

So yes, Superpowers has a spec-shaped step (brainstorming produces a design you approve). But that is one beat inside a much bigger opinionated process whose center of gravity is TDD and subagent execution, not the spec artifact.

Where it fits: you want a full, opinionated agentic SDLC with test-first discipline and parallel subagents baked in. Where it might be too much: if all you wanted was to pin down requirements before the agent codes, Superpowers brings a whole methodology along for the ride.

4. pi-sdd-kit: narrow, opinionated, gated

Now mine, and I will hold it to the same honesty. pi-sdd-kit (pi install npm:@felipefontoura/pi-sdd-kit) does one thing: spec-driven development on Pi, as five skills you invoke in order. sdd-prd, sdd-spec, sdd-tasks, sdd-exec, sdd-review. No brainstorming library, no TDD engine, no worktree manager. Just the SDD loop.

Two things carry the weight. First, steering docs as durable memory: product.md, tech-stack.md, conventions.md, and principles.md live separate from any single feature and load every session. The reason line is what pays off. “We use Postgres because payment records need ACID” stops the agent reaching for SQLite three sessions later. Second, the .status file is the only gate. One token per phase: requirements:approved, then design:approved, then tasks:approved. A finished-looking design.md on disk is not approval. Only the token is. That is what stops an eager agent racing a draft straight into code. Requirements are written in EARS (WHEN / IF / WHILE / SHALL) so there is almost nothing left to interpret.

Where it fits: you specifically want strict spec-then-approve-then-build, with a hard human gate between phases, and you are on Pi. Where it does not: you are not on Pi, or you find explicit gates annoying rather than reassuring. It is narrow on purpose: spec discipline and one hard gate, without Spec Kit’s branch-per-spec ceremony and without the advisory-only weakness of plain AGENTS.md. That is the whole design.

At a glance

Spec-driven tooling, compared

Sorted by how much process each imposes: from none (plain memory) to a full methodology (Superpowers). Enforcement is the axis that actually decides the choice.

Tool	Scope	Enforcement	Best for
Plain memory (AGENTS.md)	Durable rules only	None. Manual.	Small, solo, disciplined codebases
OpenSpec	Spec layer + change proposals	Fluid. No phase gates by design.	Spec-as-truth across any agent
Superpowers	Full SDLC methodology	Auto-triggered mandatory skills	TDD + subagents, end to end
pi-sdd-kit	SDD workflow only	Hard .status gate per phase	Strict spec-then-approve on Pi

The real fork: fluid or gated

Strip away the feature lists and one decision is doing most of the work. When the agent has a plan that looks done, is it allowed to start coding, or does a human have to say the word first?

~

Fluid (OpenSpec, plain memory)

1. 01Update any artifact anytime, keep moving.
2. 02Low ceremony, fast to iterate, great for brownfield.
3. 03The agent can act on a plan that looks complete.
4. 04Discipline lives in you, not in the tool.

|

Gated (pi-sdd-kit, Superpowers)

1. 01A phase does not advance until an explicit signal.
2. 02More friction up front, fewer wrong-direction reworks.
3. 03A finished-looking draft is not permission to code.
4. 04Discipline lives in the tool, so it survives a tired evening.

This is why “how does it compare” has no single answer. OpenSpec removes gates on purpose because ceremony slows iteration. pi-sdd-kit adds one hard gate on purpose because I was shipping money movement and a wrong-but-confident draft that reaches code is expensive. Same problem, opposite bet. Your context decides which bet is right.

The honest verdict

And they are not mutually exclusive, which is where most comparisons get it wrong. In practice people are stacking these, not choosing between them: bridge tools that wire OpenSpec’s specs into a Superpowers-style execution loop showed up within weeks. The honest axis is not a single line from less process to more. It is what the tool is built around. Spec-first (OpenSpec, Spec Kit, pi-sdd-kit) puts the specification at the center. Harness-first (Superpowers) puts the execution process at the center and treats the spec as one step. IDE-native (Kiro) puts the editor at the center. Steering docs (plain memory) sit under all of them. The point is not brand loyalty. It is knowing which problem you actually have, then adding only the process that problem needs.

If you are still deciding whether you even need spec discipline, the case study on shipping 13 apps in 70 days is the strongest argument I have. If you want the format of a good spec regardless of tool, How to Write a Spec is tool-agnostic on purpose.

FAQ

What is the difference between pi-sdd-kit and OpenSpec?+

OpenSpec is a lightweight, agent-agnostic spec layer that is deliberately fluid: you update any artifact anytime, with no rigid phase gates. pi-sdd-kit is the opposite bet. It is Pi-native and imposes a hard .status approval gate between phases, so the agent cannot advance from requirements to design to code without an explicit human token.

Both keep markdown as the source of truth. The real difference is enforcement. Pick OpenSpec if you want speed and flexibility across any agent. Pick pi-sdd-kit if you want the gate to stop the agent running ahead of you.

How does pi-sdd-kit compare to Superpowers?+

Different scope, and Superpowers is excellent. Jesse Vincent's Superpowers is a full software development methodology: brainstorming, planning, test-driven development, subagent-driven execution, and code review, all as composable skills that trigger automatically across many agents including Pi.

pi-sdd-kit does one narrow thing: the spec-driven loop (prd, spec, tasks, exec, review) with a hard approval gate, on Pi. If you want a broad, opinionated SDLC with TDD baked in, use Superpowers. If you want just the strict spec-then-approve discipline, that is pi-sdd-kit. You could even run the SDD discipline inside a Superpowers setup.

Do I need a spec tool at all, or is AGENTS.md enough?+

For a small codebase where you are solo and you refactor aggressively, plain AGENTS.md or CLAUDE.md memory is genuinely enough. Keep the files small, update them by hand, and do not add a tool.

You outgrow plain memory when you need per-feature specs, a way to agree on a change before it is built, or an enforced gate so the agent does not code the wrong thing. That is when OpenSpec, Superpowers, or pi-sdd-kit start earning their keep.

Isn't spec-driven development just waterfall rebranded?+

It is the most common objection, and it is half right. Writing intent before code is an old idea. What is new is that the spec is executable context for a non-deterministic agent, not a document that gets signed and shelved. Waterfall wrote one big spec upfront and punished change. SDD writes a small spec per change, keeps it as living memory the agent reads every session, and expects it to change.

The value was never the ceremony. It is the thinking you are forced to do before the agent codes, captured in a form the agent can execute from. If your spec is a doc nobody reads, you built the waterfall version. If it is the file the agent regenerates from, you built the useful one.

How do these compare to GitHub Spec Kit, BMAD, and Kiro?+

Spec Kit (GitHub), BMAD, and Kiro (AWS) are the heavier, more structured end of the same space. Spec Kit and BMAD are spec-first frameworks with more ceremony: branch-per-spec, many generated artifacts. The common complaint is review overload, a three-file change buried under three hundred lines of generated prose. Kiro is IDE-native, with the spec workflow inside an AWS editor and custom agents defined as markdown in .kiro/agents. See the dedicated pieces on Spec Kit and Kiro.

The axis holds: Spec Kit, BMAD, and Kiro impose more structure, OpenSpec less, plain memory none, and pi-sdd-kit adds one specific gate on a Pi-native workflow. The verbosity is a real cost. Pick the lightest tool that still closes your gap.

The tools are not really competing for the same job. They are different amounts of process bolted onto the same idea: write the intent down before the agent runs, because the agent has no memory of it. Pick the amount of process that matches the cost of being wrong.