OpenSpec vs Superpowers vs Spec Kit: Compare and Combine

Short answer: OpenSpec and Spec Kit decide what gets built, and Superpowers controls how the agent builds it. So "OpenSpec vs Superpowers" is usually the wrong fight. The setup that holds up in real repos is one planning tool (OpenSpec for fluid, brownfield changes, Spec Kit for a stricter lifecycle) plus Superpowers for execution, joined by a bridge. This page compares all three as of September 2026 and walks through both combinations.

OpenSpec vs Superpowers vs Spec Kit at a glance

Versions and commands below were checked against each project's README and docs on 2026-09-24. All three are MIT-licensed and ship new releases every few weeks, so treat the command names as current rather than permanent.

The last row is the whole argument for combining them. A schema description in OpenSpec's own community catalog puts it plainly: "OpenSpec only checks that artifacts exist", so a planning tool alone leaves execution unguarded. Superpowers guards execution hard but keeps its design and plan in a scratch location, not in a change record a reviewer can compare the diff against. For a deeper look at Superpowers on its own, see Superpowers for Spec-First AI Coding.

The useful part of SDD is not the tool name

Spec-driven development has become a crowded label. Some teams mean formal specifications. Some mean executable acceptance criteria. Some mean AI-agent workflows that turn a product idea into specs, plans, tasks, and implementation. The useful question is not which label wins. The useful question is what artifact exists before code starts, who approves it, and how the final diff proves it followed that artifact.

That is why OpenSpec, Superpowers, and GitHub Spec Kit are worth studying together. They are not identical products, and Spec Coding is not a wrapper around any of them. But they expose a set of patterns that make AI-assisted delivery less vague and more reviewable, and two of them were clearly designed to sit on top of the third.

Which SDD path should you use?

If you arrived here from search, you probably do not need a theoretical ranking. You need to know what to set up this week. Use the smallest setup that stops hidden decisions from entering the pull request.

Can you use OpenSpec and Superpowers together?

Yes, and it is the combination people ask about most. Just installing both does not work well, though. The maintainer of the most widely used bridge describes three problems that show up as soon as the two tools share a repo:

1. Duplicate design output. Superpowers brainstorming writes its design to docs/superpowers/specs/, while OpenSpec writes proposal.md and design.md in the change folder. Two documents now describe the same decision.
2. Two task lists. OpenSpec's tasks.md is a coarse checklist; Superpowers' plan is a list of TDD micro-steps. They track the same work in different places, and they drift.
3. Manual orchestration. Someone has to decide, at every step, which tool's skill runs next.

Option 1: the superpowers-bridge schema

superpowers-bridge is a custom OpenSpec schema, and it is listed in OpenSpec's own community schema catalog. It uses OpenSpec's native schema mechanism, so neither tool is modified: you copy the bundle into openspec/schemas/superpowers-bridge/, run openspec schema validate superpowers-bridge, and pick the schema per change. Its artifact graph looks like this:

brainstorm ─┬─→ proposal ─→ specs ─┐
            └─→ design ────────────┴─→ tasks

tasks ─→ plan ─→ [apply] ─→ verify ─→ retrospective

What changes compared with plain OpenSpec: the change starts with a Superpowers brainstorm instead of a hand-written proposal, tasks.md gains a Superpowers plan.md underneath it, apply runs in a git worktree through subagent-driven-development (which pulls in TDD and code review), and two artifacts are added after apply: verify.md and an evidence-first retrospective.md. Brainstorming and writing-plans output is redirected into the change folder, which fixes problems 1 and 2.

/opsx:new refund-retry --schema superpowers-bridge   # or /opsx:ff refund-retry
/opsx:apply      # worktree + subagent-driven-development (TDD, code review)
/opsx:verify     # writes verify.md
/opsx:continue   # writes retrospective.md, then archive and open the PR

Four things to know before you adopt it:

• It only fires through /opsx:* commands. If you say "let's brainstorm the architecture" in plain chat, Superpowers runs its default flow and writes to docs/superpowers/specs/ again. The README treats that as the main failure mode.
• It needs a subagent-capable agent. There is deliberately no fallback to the cheaper executing-plans skill, because that path does not pull in TDD and code review.
• Check version drift. At the time of writing, the README states compatibility baselines of OpenSpec 1.4.1 and Superpowers v5.1.0, while current releases are 1.13.2 and 6.4.1. Run the validate command and look at the repo's open "upstream-version-check" issues before relying on it.
• Not every change needs it. The bridge's own guidance sends bug fixes, test backfill, config tweaks, and dependency bumps straight to a normal PR. Ceremony should scale with risk.

Option 2: a hand-written routing rule

If you do not want a third-party schema, you can get most of the benefit with a short section in AGENTS.md or CLAUDE.md. It is weaker, because nothing validates it and the agent can ignore it, but it removes the duplicate documents and gives reviewers one place to look:

## Planning vs execution
- New capability, breaking change, or architecture change:
  open an OpenSpec change first (/opsx:propose <name>).
- Superpowers brainstorming output goes into
  openspec/changes/<name>/design.md, not docs/superpowers/specs/.
- writing-plans output goes into openspec/changes/<name>/plan.md;
  tasks.md stays the checklist reviewers tick.
- Bug fixes, typos, dependency bumps: no change folder, normal PR.
- A task is done when its tests pass and every diff hunk maps
  to a line in tasks.md.

Where that file belongs and what else goes in it is covered in AGENTS.md for Spec-First Teams.

Spec Kit and Superpowers together

The same split works with Spec Kit. speckit-superpowers-bridge, listed in Spec Kit's community extension catalog, sums itself up as "Spec Kit writes WHAT. Superpowers enforces HOW." Spec Kit stays the source of truth for constitution, spec, plan, and tasks. After /speckit-tasks, a hook writes a small handoff file, .specify/superpowers-handoff.json, and the bridge command hands tasks.md to native Superpowers skills for execution, verification, review, and branch finishing.

specify init my-project --integration claude
specify extension add speckit-superpowers-bridge \
  --from https://github.com/lihan3238/speckit-superpowers-bridge/releases/latest/download/speckit-superpowers-bridge.zip
# then: /speckit-specify → /speckit-clarify → /speckit-plan → /speckit-tasks → /speckit-superpowers-bridge

The bridge's argument is that Spec Kit's bundled implement step is a single agent run with no TDD, no subagent fan-out, and no structured review. That was more true before Spec Kit 1.0 added /speckit-converge, which re-checks the implementation against spec, plan, and tasks and appends missing work to tasks.md. Converge answers "did we build everything?"; Superpowers answers "did we build it test-first and get it reviewed?" They overlap less than it first looks. The bridge's verified baselines, Spec Kit 0.16.4 and Superpowers 6.3.0 at the time of writing, trail the current releases, so test it on a throwaway feature first.

All-in-one plugins

A third option is a single plugin that merges the two ideas. The most active one we found is spec-superflow (npm spec-superflow, Chinese-first docs), which combines OpenSpec-style planning with Superpowers-style verification. Its v2 cut new work down to two paths, direct for small scoped changes and planned for changes that need a proposal.md and tasks.md approved once. The tradeoff is dependence: you stop receiving upstream OpenSpec and Superpowers improvements directly and rely on one maintainer to fold them in.

"SDD" means something else inside Superpowers

If you searched for "Superpowers SDD", you may have been looking for a skill rather than a methodology. In Superpowers, SDD usually refers to subagent-driven-development: it dispatches a fresh subagent for each task in the plan and runs a two-stage review after each one, first for spec compliance and then for code quality. Its cheaper sibling, executing-plans, runs every task in the current session with one review at the end.

That is not spec-driven development, but the two fit together exactly where the bridges connect them: the spec and task list come from OpenSpec or Spec Kit, and subagent-driven-development executes against them.

Worked request: refund a failed invoice

Here is the small request we use to choose between the paths: "Let support admins refund a failed invoice." It sounds narrow, but it touches policy, billing API behavior, ledger export, audit logs, and agent implementation scope. A chat-only prompt would let those decisions leak into code.

spec.md excerpt:
- Goal: allow support admins to refund failed invoices once.
- Non-goals: partial refunds, ledger schema changes, email template changes.
- Acceptance: duplicate click returns the same refund_id.

tasks.md excerpt:
- Add POST /api/invoices/:id/refund within billing/refunds.ts.
- Add idempotency fixture and audit-log assertion.
- Do not modify ledger export fields.

evidence.md excerpt:
- test: refund_failed_invoice_once
- log: audit_event_type = invoice_refund_requested
- reviewer: billing owner signs off on role boundary

The failure case is easy to miss: without the packet, an assistant may "helpfully" add partial refunds or change the ledger export because the prompt never said not to. The artifact chain turns that invisible product decision into a reviewable line.

Pattern 1: create a durable artifact before implementation

OpenSpec organizes a change around proposal.md, a specs/ folder of requirements with scenarios, design.md, and tasks.md, and folds the accepted specs back into openspec/specs/ when the change is archived. Spec Kit writes a project constitution once, then a spec, a plan, and tasks per feature. Superpowers starts by teasing a design out of the conversation and showing it in chunks short enough to read. Different vocabulary, same move: the agent should not jump straight from a chat prompt to a diff.

For a team, the concrete rule can be simple. Before code generation, a feature should have at least one durable file that names the goal, non-goals, acceptance criteria, owner, dependencies, and evidence requirement. A chat transcript is not enough. If the requirement only exists in the model context, nobody can review it later, rerun it, or compare the final code to it. For the lightweight version of this practice, see the Spec as Code Hub, and for the fields that durable file should carry, the technical spec template guide.

Pattern 2: separate product intent from technical planning

Spec Kit makes this separation explicit: define what and why before deciding how. OpenSpec similarly separates the proposal and specs from design and tasks. This matters because AI coding tools are quick to collapse product ambiguity into implementation detail. The moment a model chooses the database shape, API boundary, and UI behavior before the product question is settled, the team has lost control of the decision path.

A strong Spec Coding workflow keeps those layers separate:

Pattern 3: avoid rigid ceremony unless risk demands it

OpenSpec's stated philosophy is "fluid not rigid, iterative not waterfall", built for brownfield code rather than only greenfield. That is a useful correction to the worst version of SDD: a big pile of Markdown that blocks work without improving review quality. A spec process should scale with risk. Authentication, payments, data migrations, public APIs, and AI-generated changes need stronger gates than a typo fix. Both bridges above make the same point from the other side by sending small fixes straight to a normal PR.

The minimum useful version is a one-page spec packet. The maximum useful version may include a constitution, requirements, technical design, task breakdown, migration plan, risk register, and test evidence. The key is to choose the smallest artifact set that still prevents hidden decisions from landing in code review.

Pattern 4: turn tasks into verifiable units

Superpowers is especially strong here. Its writing-plans skill breaks work into bite-sized tasks of a few minutes each, with exact file paths and verification steps, written so that an implementer with no project context could follow them. It then enforces red/green TDD while executing. That is the missing bridge in many AI coding workflows: a spec alone is not enough if the next step is a giant prompt that asks the model to "build everything."

Break the plan into tasks that include file scope, acceptance criteria, test expectations, and review notes. A good task is not just "add retry logic." It is closer to:

Task: add timeout retry to refund worker
Write scope:
- src/billing/refund-worker.ts
- src/billing/refund-worker.test.ts

Acceptance:
- timeout once -> retry with same idempotency key
- timeout twice -> keep pending status, no duplicate refund_id

Evidence:
- test: refund_timeout_replay
- log query: duplicate_refund_attempts remains zero

That kind of task gives the coding agent room to implement, but not room to decide the product policy.

Pattern 5: make review evidence part of the workflow

All three projects are ultimately trying to close the gap between "the assistant produced code" and "the team can trust the change", and all three now have an explicit check after implementation: OpenSpec's /opsx:verify in the expanded profile, Spec Kit's /speckit-converge, and Superpowers' verification-before-completion and code-review skills. The missing word is still evidence. The spec should define what proof the reviewer expects: tests, fixture names, logs, screenshots, contract checks, migration dry runs, or rollout metrics.

This is where Spec Coding differs from a pure tooling comparison. We care less about which command starts the workflow and more about the artifact chain a reviewer can inspect:

ticket.md
  -> spec.md
  -> design.md
  -> tasks.md
  -> tests + evidence.md
  -> PR review

If any link is missing, the team should know why. If an AI-generated PR cannot map its changes back to a task and a criterion, the PR is not ready. The spec review checklist is the gate we use before the first task starts.

Where each tool shines

A repo layout that works without buying into any tool

You can adopt the core of SDD without choosing a framework first. Start with a simple repository layout that any coding agent can read and any human can review:

/specs
  /active
    refund-retry/
      spec.md
      design.md
      tasks.md
      evidence.md
  /archive
    2026-05-11-refund-retry/
/templates
  feature.spec.md
  api-contract.spec.md
  ai-coding-review.md
/docs
  engineering-principles.md

That layout borrows from OpenSpec's change folders, Spec Kit's separation of principles from per-feature work, and Superpowers' insistence on planning before execution. It also stays portable: if the team later adopts one of the tools, the artifacts are already in the right shape, and moving specs/active/<name>/ into openspec/changes/<name>/ is mostly a rename.

Decision guide

Start with a lightweight spec packet when the change is narrow, low risk, and fits one pull request. Add OpenSpec when changes need a proposal, design, task split, and an archived record, especially in an existing codebase. Choose Spec Kit instead when the organization wants the same lifecycle and gates on every feature. Add Superpowers to either one when the agent's behavior during implementation is the problem, and connect them with a bridge or a routing rule so there is one plan, not two.

The important thing is not to let the workflow become theatrical. A good SDD process should reduce clarification comments, make tests easier to write, and make PR review less subjective. If it only creates more documents, tighten it until every artifact changes a decision or proves a behavior. The checks that enforce those artifacts on every change, whichever tool wrote them, are the subject of Harness Engineering vs Spec-Driven Development.

What changed in the September 2026 review

This article first compared the three projects in May 2026. The main differences since then, from each project's README and docs:

• OpenSpec was rebuilt around an artifact-guided workflow invoked as /opsx:propose, /opsx:apply, and /opsx:archive, with /opsx:explore for thinking before committing to a change and an expanded profile that adds /opsx:verify, /opsx:ff, and others. It added Stores (beta) for planning in a separate repo shared across a team, and a catalog of community schemas, which is where superpowers-bridge lives. It lists support for 30+ AI tools.
• Spec Kit reached 1.0. Processes are now invoked as /speckit-* agent skills (some agents use /speckit.*), /speckit-converge closes each feature, and bug fixing and idea assessment ship as installable extensions alongside SDD.
• Superpowers moved to the 6.x line and is installable from the official Claude Code and Codex plugin marketplaces as well as a dozen other harnesses. The workflow now offers executing-plans as a cheaper inline alternative to subagent-driven-development, and a diagnosing-superpowers skill for sessions that misbehave.

References

• Fission-AI/OpenSpec and its community schema catalog
• github/spec-kit and the SDD command reference
• obra/superpowers and the original release announcement
• JiangWay/openspec-schemas: superpowers-bridge
• lihan3238/speckit-superpowers-bridge
• MageByte-Zero/spec-superflow