OpenSpec vs. Spec Kit vs. Superpowers: SDD Tools Compared

Every time I post about my own spec-driven setup, the same questions come back. How does this compare to OpenSpec? To Spec Kit? 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. Five ways to give an AI agent the intent it does not have on its own, sorted roughly by how much process each one forces on you. I ship one of them (pi-sdd-kit). It goes last, so you can judge it against the others, 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 whatever agent you already use, and it supports more than 30 of them now. You install it with npm or Homebrew, 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. An expanded profile adds steps like /opsx:verify and /opsx:continue when you want more structure.

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. Newer releases add Stores (in beta): the same specs and changes kept in a planning repo of their own, so a feature that lands in three repos still gets one plan.

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, 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.

I ran one real change through OpenSpec 1.14, from install to archive, in the OpenSpec tutorial, with every command and the right spelling for each agent.

3. Spec Kit: GitHub’s structured pipeline

Spec Kit (GitHub, MIT, about 140k stars) is the structured end of spec-first, and it hit 1.0 in August. You install the specify CLI with uv (it needs Python 3.11 or newer), run specify init with the integration for your agent, and then drive the agent through a fixed sequence. /speckit-constitution runs once per project and writes the principles every feature must answer to. Then, per feature: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement. Optional steps slot in when you want extra checks: /speckit-clarify before the plan, /speckit-analyze for consistency across the artifacts, /speckit-checklist for what amounts to unit tests for English.

The step added in June is the interesting one. /speckit-converge compares what got built against the spec, the plan, and the tasks, and appends whatever is missing as new tasks. You loop implement and converge until it reports converged. That is Spec Kit admitting what everyone learned the hard way: the agent says done before it is done.

Two things changed since the first wave of criticism. Branch-per-spec is opt-in now: the active feature lives in .specify/feature.json, and numbered feature branches come from a git extension you add yourself. And Spec Kit stopped being only SDD. Bug fixing (assess, fix, test) and idea assessment (a go or kill decision before you build anything) ship as extensions.

Where it fits: you want a documented pipeline that runs the same way for every feature, with a constitution that every feature answers to. Teams like that, because every change produces the same artifacts in the same places. Where it might not: the verbosity is real. The most common complaint has not changed: a three-file change buried under hundreds of lines of generated prose that somebody has to review. You can cut it with the bundled lean preset (specify preset add lean), which brings each phase down to one focused file, but you have to choose it. And the order is rigid, but the approval is not. The tool checks that the plan exists. It does not check that a human read it.

I wrote a full Spec Kit walkthrough if you want every command in detail.

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

Superpowers (Jesse Vincent and Prime Radiant, MIT, close to 300k 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 (tasks of two to five minutes each, with exact file paths and verification steps), subagent-driven-development (a fresh subagent per task, reviewed for spec compliance and then code quality) or the cheaper executing-plans (inline, one review of the whole branch at the end), test-driven-development (real RED-GREEN-REFACTOR, it deletes code written before a test), requesting-code-review, and finishing-a-development-branch. It runs in Claude Code, where it sits in Anthropic’s official plugin marketplace, and in Codex, Cursor, Gemini CLI, Copilot CLI, 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. The design doc and the plan serve the feature in flight. Nothing folds them into a long-lived spec of the system once the work ships.

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.

5. 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 volume of generated artifacts and without the advisory-only weakness of plain AGENTS.md. That is the whole design.

Spec Kit vs. OpenSpec: same bet, different weight

Spec Kit and OpenSpec agree on the part that matters. The spec is the source of truth, and the agent works from it. They disagree on how much ceremony it takes to get there.

~

OpenSpec

1. 01Node CLI. openspec init and you are done. 30+ assistants.
2. 02One folder per change: proposal, specs, design, tasks.
3. 03Update any artifact anytime. No phase gates, by design.
4. 04Archive merges each change back into the living specs.
5. 05Built for existing codebases first.

|

Spec Kit

1. 01Python CLI via uv. specify init with one integration per agent.
2. 02A constitution once, then specify, plan, tasks, implement.
3. 03Phases run in order, with optional clarify, analyze, checklist.
4. 04Converge loops until the code matches the artifacts.
5. 05More Markdown per change, and someone has to read it.

The tell is in their own words. OpenSpec’s README calls Spec Kit thorough but heavyweight. Spec Kit keeps moving the other way, with converge and a catalog of extensions: more structure, not less. Neither one is wrong. They are built for different weights of change.

My rule: count the lines a reviewer has to read for a three-file change. If the spec artifacts run longer than the diff, the tool is too heavy for that change. Small, frequent changes on an existing codebase sit closer to OpenSpec’s weight. A new product with a team that needs every feature to answer to the same principles is where Spec Kit’s constitution and fixed sequence pay for the extra Markdown.

OpenSpec vs. Superpowers: they do different jobs

This is the question I get most, and it is a slightly wrong question. OpenSpec and Superpowers do not compete.

OpenSpec owns the what and the why: a proposal, the requirements, and a spec that outlives the change. Superpowers owns the how: a plan cut into tasks of a few minutes, tests first, a fresh subagent per task, review before merge. OpenSpec has no opinion on whether you write tests first. Superpowers has nowhere to keep the reason a requirement exists, six months after it shipped.

So pick by the failure you keep having. If the agent builds the wrong thing, or forgets a decision from three sessions ago, you have a spec problem, and that is OpenSpec. If the agent builds the right thing badly, skips the tests, or wanders off the plan after an hour, you have an execution problem, and that is Superpowers. If you have both problems, you are not choosing. You are stacking.

Using OpenSpec and Superpowers together

Stacking them is the most common setup I see, and it works when each tool keeps to its lane.

One change, two tools

Input

A change worth more than one session

↓

1. OPENSPECExplore and propose

   /opsx:explore to think it through, then /opsx:propose to write the proposal, the delta specs, the design, and the tasks. This is the record that survives.

   ↓
2. YOURead the proposal

   The step neither tool enforces. Nothing moves until a human has read the spec and said yes.

   ↓
3. SUPERPOWERSPlan and build

   writing-plans turns the approved tasks into small steps. Then test-driven development, a fresh subagent per task, and review between tasks.

   ↓
4. OPENSPECArchive

   /opsx:archive folds what actually shipped back into the specs, so the next session starts from the truth instead of the plan.

↓

Output

OpenSpec remembers why. Superpowers controls how well. You decide when.

Two rules keep them from fighting. First, one design step, not two. Superpowers’ brainstorming and OpenSpec’s explore and propose cover the same ground. Run both and you get two designs that drift apart. Let OpenSpec write the design, and tell Superpowers to plan from the approved change folder. Second, write the routing down. A short section in AGENTS.md or CLAUDE.md that says which tool owns which phase is what stops the agent from improvising the handoff.

You do not have to wire it by hand. OpenSpec lists community schemas in its docs, and one of them, superpowers-bridge, does this handoff at the prompt layer and adds a retrospective artifact after the work ships. Check its compatibility line before you adopt it. As of September 30, its README lists OpenSpec 1.4.1 and Superpowers v5.1.0 as the tested baseline, while the current releases are 1.14 and 6.4.2. Prompt-layer glue survives version drift better than code does. It is still drift.

Here is the part no combination solves for you. Neither tool stops the agent between a proposal that looks approved and the code. OpenSpec is fluid by design. Superpowers asks for your sign-off in the conversation, and an eager agent, or a tired you at 11pm, can wave that through. Even the OpenSpec community schema built around an adversarial review step (anvil) says it plainly in the catalog: OpenSpec only checks that artifacts exist, so enforce the gate with your own CI or hook. That gap is what I built pi-sdd-kit around. On any other stack you close it the same way: a status file or a hook that refuses to run apply until a human token is there.

What about BMAD and Kiro?

Both come up in every thread, so briefly.

BMAD (v6.12, about 54k stars) calls itself agile AI-driven development. It brings specialized perspectives for product, architecture, UX, development, and testing, and it sizes the planning to the change: small changes go straight to build, complex work gets briefs, specifications, and architecture before any code. It is the most role-heavy option on this list. Close to Superpowers in scope, but organized around an agile team instead of around TDD. I ran one real feature through it in Claude Code, with the cost and the gate it does not hold, in my BMAD Method guide.

Kiro is the AWS IDE with the spec workflow built in: requirements, design, and tasks inside the editor. Pick it if you want SDD without assembling anything yourself and you are happy living in that editor.

At a glance

Spec-driven tooling, compared

Sorted roughly by how much process each one imposes, with mine last. 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
Spec Kit	Constitution + sequenced pipeline	Ordered phases, approval by convention	Teams that want the same artifacts every time
Superpowers	Full SDLC methodology	Auto-triggered mandatory skills	TDD + subagents, end to end
BMAD	Agile roles + scaled planning	Guided workflows	Role-based planning on larger work
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.

Spec Kit sits in the middle: the order is enforced, the approval is not. That 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.

Same brief, four tools: what each one did

Opinions about these tools are cheap, mine included. So on October 13 I ran the test. One small feature with a money edge, the same request word for word, the same repo at the same commit, the same model, through four tools. Two of the runs have their own write-ups with every command: the OpenSpec tutorial and the BMAD Method guide. This section puts all four side by side.

The setup, identical for every tool

October 13, 2026. Spec Kit ran the existing-project path: constitution, specify, clarify, plan, tasks, analyze, implement, converge. Superpowers got the plain request, because its skills are supposed to trigger on their own.

What	Value
Repo	An in-memory ledger: a 24-line src/ledger.js, two tests, one base commit
Request	Make transfers idempotent. transfer() takes an idempotency key. A retry with the same key and the same from/to/amount returns the original result and moves no money. The same key with a different payload is rejected with an error. Keys live in memory, like the balances.
Model	claude-opus-5-5 in Claude Code 2.1.296, headless, a fresh clone per tool
Versions	OpenSpec 1.14.1, BMAD 6.12.2, Spec Kit 1.2.0, Superpowers 7.0.0
My answers	BMAD, Spec Kit and Superpowers got the same two, asked or not: the key is required, and only successful transfers save it. OpenSpec asked nothing and got one correction: make the key required
Flow	Each tool's documented path, every stop approved the way I approve real work
Cost	Claude Code's API-equivalent figure, subagents included. Not what I paid

The request leaves two decisions open, and both matter on a money path. Is the key required? An optional key means the one caller who forgets it can still charge twice. And does a failed transfer use up its key? Before the Spec Kit and Superpowers runs, I wrote a 13-item acceptance check: five items for what the request says, six for the calls a payments engineer would make on a money path (two of them are the answers I gave out), plus the repo’s own test suite and a commit. One script checked the first eleven on all four final repos; I checked the last two by hand.

What each run cost and what it shipped

Agent time is the sum of every turn, first prompt to last reply. Input tokens, cache included: 2.15M, 1.88M, 3.80M and 0.23M. Spec lines are the plan artifacts committed with the feature; OpenSpec also folds a 54-line living spec in at archive, and Spec Kit also wrote a 99-line constitution. All four end with every repo test passing (10, 10, 12 and 8 tests). n=1 per tool.

Tool	Agent time	List price	My prompts	Spec lines	Acceptance
OpenSpec 1.14.1	277 s	$2.16	6	136	12/13
BMAD 6.12.2	217 s	$1.89	3	88	13/13
Spec Kit 1.2.0	473 s	$2.84	10	690	13/13
Superpowers 7.0.0	40 s	$0.33	2	0	13/13

The code converged. Same model, same request, four working ledgers within one item of each other. The one miss was OpenSpec’s: a replay hands back the stored result object itself, so a caller who edits it changes what every later replay returns. The other three return a copy or a frozen object. What the tools changed was the bill, more than eight times apart, and how the open decision reached me.

How the key decision surfaced, and who holds the gate

The prompt means an instruction in the agent's context is the only thing that stops it; in the BMAD probe, one sentence from me overrode it. None of the four records a human approval anywhere code can check. Spec Kit's one code check is on the order of steps, and it only asks whether files exist.

Tool	Required or optional key	Approval held by
OpenSpec	Decided optional, flagged it for review before code. Fixed with a correction round	The prompt. validate --strict checks structure, not approval
BMAD	Asked before code, recommended required	The prompt. One sentence of pre-approval skipped both stops in a probe
Spec Kit	Asked before the plan, recommended optional	The prompt. A script refuses implement without plan.md and tasks.md, but an empty plan.md passes
Superpowers	Decided required on its own, told me after the code was written	The prompt, and here the prompt lost: brainstorming never ran

Spec Kit was the most thorough and the most expensive. It asked the right question and recommended the wrong answer: “I recommend B, because it keeps transfer’s current behaviour and the existing tests unchanged.” The analyze step earned its turn. It found four tests in its own task list that would pass before the feature existed, and I accepted six of its ten findings. But the bill is ten prompts, 690 lines of spec and $2.84 for a ledger change of nine lines. There is no commit step either: core leaves git to an opt-in extension, so I made the branch and the commit myself. The implement step also created a .gitignore, because its own instructions require one.

Superpowers was the opposite. Forty seconds, 33 cents, two prompts. It loaded test-driven development, wrote six tests, watched three fail, made them pass, and listed its choices afterward. The two that mattered, a required key and keys saved only on success, were right. What it skipped was its own front door: the using-superpowers skill it injects at session start tells the agent to brainstorm first on any “let’s build X”, and the brainstorming skill says it must run before modifying behavior. It never loaded. When I invoked brainstorming by hand on a clean copy, it asked one question before code (what happens to a failed transfer’s key), described the change in chat, and said “Nothing gets built until you approve it.” That run cost $0.40 and passed the same check. The process is real. Whether it runs was the model’s call, which also corrects my own table above: I put Superpowers on the gated side, and on this run the gate was a suggestion. One more trap: Anthropic’s official plugin marketplace installed Superpowers 6.4.1; version 7.0.0 came from the author’s own marketplace.

OpenSpec and BMAD are covered in depth in their guides. The short version: OpenSpec guessed optional and told me, and I paid a correction round for it. BMAD was the only one of the four to ask both questions before writing a line of code.

My bet, from one run each: on a change this small, the model does the engineering either way, and the process mostly adds cost. Its one chance to earn that cost is the open decision, and there the record is mixed. BMAD asked and recommended right. Spec Kit asked and recommended wrong. OpenSpec guessed wrong and told me before code. Superpowers guessed right and told me after. And in all four, the approval lives in the prompt. If the gate matters, put it on disk.

The honest verdict

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. Role-first (BMAD) puts a simulated agile team at the center. 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

Is OpenSpec better than Spec Kit?+

Neither is better in the abstract. They agree that the spec is the source of truth and disagree on weight. OpenSpec is a light Node CLI with one folder per change, no phase gates, and a strong fit for existing codebases. Spec Kit is a Python CLI with a constitution and a fixed sequence (specify, plan, tasks, implement, converge) that produces more artifacts per change.

Pick OpenSpec when your changes are small and frequent and you want to keep moving. Pick Spec Kit when a team needs every feature to go through the same documented pipeline and can afford to review the extra Markdown.

Can you use OpenSpec and Superpowers together?+

Yes, and it is the most common stack I see. OpenSpec owns the proposal, the specs, and the archive. Superpowers owns planning, test-first implementation, subagents, and review. Use one design step, not both, and write down in AGENTS.md or CLAUDE.md which tool owns which phase.

The community superpowers-bridge schema for OpenSpec wires the handoff for you. Check its tested versions first: as of September 2026 it lists OpenSpec 1.4.1 and Superpowers v5.1.0, well behind the current releases. And add your own approval gate between proposal and apply, because neither tool enforces one.

Which spec-driven development tool works best with Claude Code?+

Every tool here runs in Claude Code except pi-sdd-kit, which is Pi-native. Superpowers installs from Anthropic's official plugin marketplace, OpenSpec and Spec Kit install their commands or skills into Claude Code on init, and BMAD ships a Claude Code plugin. Claude Code is not the constraint. Your problem is.

If the agent forgets decisions, start with OpenSpec. If it executes sloppily, start with Superpowers. If you want to run the loop in Claude Code with no framework at all, my Spec-Driven Development with Claude Code guide walks through it with plain files.

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, Spec Kit, 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.

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.