OpenSpec vs Superpowers: Which SDD Framework Should You Choose?
I was trying to choose a spec-driven development framework for my team’s AI-assisted coding workflow, and I hit a wall. I’d been hearing about both OpenSpec and Superpowers, but the documentation didn’t make it clear which one fit our needs. Was I looking for better spec management? Or stricter code quality enforcement? The line between them was blurry.
After spending a week testing both frameworks on real projects, I finally understand the core difference: OpenSpec excels at decision traceability, while Superpowers excels at execution quality. Let me walk you through what I learned so you can make the right choice for your project.
The Problem: Two Frameworks, Similar Goals, Different Priorities
Both OpenSpec and Superpowers implement spec-driven development (SDD), but they solve different problems. I initially thought they were competing solutions—turns out they’re complementary approaches with distinct philosophies, and as of 2026 the community is actively combining them.
Here’s the fundamental question you need to answer: Does your team care more about documenting why changes were made, or enforcing how changes are implemented?
If you answered “documenting why,” you’re leaning toward OpenSpec. If you said “enforcing how,” Superpowers is your answer. Let me explain why.
OpenSpec: The Decision Historian
I tested OpenSpec on a large enterprise project with strict compliance requirements. What immediately stood out was the change management structure.
┌─────────────┐│ Explore │ Understand the codebase└──────┬──────┘ ▼┌─────────────┐│ Proposal │ What should change and why?└──────┬──────┘ ▼┌─────────────┐│ Design │ How will it change?└──────┬──────┘ ▼┌─────────────┐│ Specs │ Formal specification└──────┬──────┘ ▼┌─────────────┐│ Tasks │ Break down to features└──────┬──────┘ ▼┌─────────────┐│ Apply │ Implement the changes└──────┬──────┘ ▼┌─────────────┐│ Verify │ Confirm it works└──────┬──────┘ ▼┌─────────────┐│ Archive │ Store for future reference└─────────────┘The key innovation here is the delta spec system. When you propose a change, you create a delta spec that describes only what’s different. When the change is approved and implemented, this delta syncs back to the main spec. The two-folder model (openspec/specs/ for current truth, openspec/changes/ for proposed updates) is deliberately brownfield-first: it scales best when you’re modifying existing features and touching multiple specs, not just generating greenfield ones.
The newer fluid (OPSX) workflow also drops the rigid phase ordering. Instead of marching Explore→Proposal→…→Archive, you work in actions—new, continue, apply, archive—in any order, with dependencies (not phases) gating progress. You can create artifacts one at a time or fast-forward, and update specs/design/tasks during implementation. Slash commands like /opsx:sync (merge a delta spec into the main spec) and /opsx:verify (validate completeness, correctness, and coherence of the implementation against the change artifacts) keep the spec and code in lockstep, while the openspec update CLI regenerates AI-tool config files after CLI upgrades.
What I Loved About OpenSpec
-
Spec Knowledge Base: My specs are organized by capability, not by feature. I can query “how does authentication work” and get a comprehensive answer from the main spec, and capabilities even retire automatically when a change removes their last requirement.
-
Audit Trail: Every change has a proposal → design → spec → task chain. When compliance asks “why did we make this change?”, I have the documentation.
-
Platform Agnostic, and Broadly So: As of v1.8,
openspec init --toolssupports 30+ AI tools—Claude Code, Cursor, Copilot, Codex, OpenCode, the vendor-neutralagents(AGENTS.md-compatible) target, MiniMax, Rovo Dev CLI, and more—generated into each tool’s canonical skills/commands directory. No special platform requirements. -
Stores: Repositories can register multiple OpenSpec roots (“stores”) and select one with
--store <id>(oropenspec store list), so a monorepo can keep several independent spec namespaces without cross-contamination.
What Frustrated Me
-
No TDD Enforcement: I could skip tests entirely. The framework assumes I’m disciplined enough to write them. (
/opsx:verifywarns about missing coverage, but it doesn’t force tests.) -
Single Agent Model: No built-in code review mechanism. I had to self-review using checklists.
-
Manual Git Workflow: The framework doesn’t enforce branch isolation. I had to manage git discipline separately.
Superpowers: The Quality Enforcer
Then I tried Superpowers on a greenfield project. The first thing that happened? I got blocked by failing tests.
┌─────────────────┐│ Brainstorming │ Socratic Q&A to explore requirements└────────┬────────┘ ▼┌─────────────────┐│ Git Worktree │ Isolated development environment└────────┬────────┘ ▼┌─────────────────┐│ Writing Plans │ 2-5 min steps with code examples└────────┬────────┘ ▼┌─────────────────┐│ Subagent Dev │ Controller + Implementer + Reviewers└────────┬────────┘ ▼┌─────────────────┐│ Finishing Branch│ Merge, PR, or discard└─────────────────┘The subagent architecture is the secret sauce. Here’s what happens:
- Controller Agent: Reads the plan, coordinates implementation
- Implementer Agent: Writes code in isolation
- Reviewer Agent: Provides objective, third-party code review
What I Loved About Superpowers
-
Mandatory TDD: The framework enforces RED-GREEN-REFACTOR. I literally couldn’t proceed without tests.
-
Git Worktree Isolation: Each change happens in its own worktree. No more “oops, I committed to main branch.”
-
Objective Code Review: The reviewer agent has no ego. It catches issues I’d miss in self-review.
What Frustrated Me
-
Harness Dependency (but Less Than Before): It used to be Claude Code/Cursor/Gemini only. As of v6.0 (June 2026) harness support broadened to Codex CLI, OpenCode, Copilot CLI, Kimi Code, Pi, and Antigravity (
agy). Note: Gemini CLI support was actually removed in v6.1 (end-of-life), and plain ChatGPT still isn’t supported—you need a subagent-capable harness. So pick a supported harness, but you’re no longer locked to one vendor. -
Token Cost (Improved in v6.0+): Running multiple agents used to burn tokens fast—my first week cost 3x what I expected. The v6.0+ line consolidated bootstrap injection (especially for OpenCode) and made the SDD workspace plan-scoped, which removed 6–13 tool calls of cross-plan git forensics per resume. Net effect in my runs: token consumption roughly halved versus the early baseline, with noticeably faster turn-around.
-
No Spec Management: There’s no independent spec directory. Design decisions are embedded in the design doc, which gets messy over time.
Head-to-Head Comparison
Let me show you the practical differences I discovered:
| Dimension | OpenSpec | Superpowers ||--------------------|--------------------------------|------------------------------------|| Core Focus | Change management | Code quality || TDD | Optional (verify warns) | Mandatory || Multi-Agent | No | Yes (3+ agents) || Spec Storage | Independent specs/ (delta) | Embedded in design.md || Git Integration | Manual | Automatic worktrees || Review Process | Self-checklist (+/opsx:verify) | Subagent review || Platform Support | 30+ AI tools (--tools) | 8+ harnesses (v6.0+) || Token Efficiency | High | Medium (v6.0+ ~halved vs early) || Change Audit Trail | Complete (proposal→archive) | Partial (plan→PR) || Workflow Model | Fluid actions (OPSX) | Phased (brainstorm→finish) || Brownfield-first | Yes (two-folder model) | Greenfield-biased |When to Choose OpenSpec
I recommend OpenSpec when:
- You’re working on a large enterprise project with strict compliance requirements
- Your team needs long-term spec maintenance (queryable knowledge base + Stores for multi-root repos)
- You’re evolving an existing codebase rather than starting from scratch (brownfield-first)
- You don’t have a subagent-capable harness (using ChatGPT, Copilot, etc.)
- Change documentation matters more than code enforcement
Here’s the scenario that convinced me:
Scenario: Financial services company updating payment processingRequirement: Every change must be traceable for auditsSolution: OpenSpec's proposal → design → spec → archive chain, with /opsx:sync merging deltas and /opsx:verify validating the resultResult: Compliance team can trace any change to its rationaleWhen to Choose Superpowers
I recommend Superpowers when:
- You’re starting a greenfield project from scratch
- Your team has strict TDD requirements (or wants them)
- You’re on a supported harness—Claude Code, Cursor, Codex CLI, OpenCode, Copilot CLI, Kimi Code, Pi, or Antigravity
- Code quality matters more than spec documentation
Here’s where it shone:
Scenario: Startup building MVP with strict testing requirementsRequirement: Every feature must have comprehensive test coverageSolution: Superpowers' mandatory TDD + subagent reviewResult: 95%+ test coverage from day one, objective code reviewsThe Decision Matrix
I created this decision tree to help you choose:
START │ ├─ Is your harness subagent-capable (Claude Code, Cursor, Codex, │ OpenCode, Copilot CLI, Kimi Code, Pi, Antigravity)? │ ├─ No → OpenSpec (only option here) │ └─ Yes → Continue │ ├─ Is this a greenfield project? │ ├─ Yes → Superpowers (built for new projects) │ └─ No → Continue │ ├─ Do you need strict TDD enforcement? │ ├─ Yes → Superpowers (mandatory TDD) │ └─ No → Continue │ ├─ Do you need long-term spec maintenance / brownfield evolution? │ ├─ Yes → OpenSpec (spec knowledge base + Stores) │ └─ No → Continue │ ├─ Does your team require change audit trails? │ ├─ Yes → OpenSpec (proposal→archive chain) │ └─ No → Superpowers (faster iteration) │ └─ TOKEN_BUDGET_CONSTRAINT? ├─ Tight → OpenSpec (single agent) └─ Loose → Superpowers (v6.0+ multi-agent, now ~half the old cost)Practical Example: Same Feature, Different Frameworks
Let me show you how the same feature looks in both frameworks. I’ll implement a user authentication feature.
OpenSpec Approach
1. EXPLORE: Analyze current auth implementation Output: Current state documented in exploration.md
2. PROPOSAL: "Add OAuth2 support for Google/Facebook" Output: proposal.md with rationale and impact analysis
3. DESIGN: Technical architecture decisions Output: design.md with sequence diagrams and API specs
4. SPECS: Formal specification Output: specs/auth-oauth2.md (delta spec) - /opsx:sync merges it into the main spec - Independent, queryable document
5. TASKS: Feature breakdown Output: tasks.md with: - Task 1: Add OAuth2 provider interface - Task 2: Implement Google OAuth2 - Task 3: Implement Facebook OAuth2 - Task 4: Update UI for social login
6. APPLY: Implement each task (single agent)7. VERIFY: /opsx:verify checks completeness, correctness, coherence8. ARCHIVE: Store all artifacts; retire replaced capabilities if anySuperpowers Approach
1. BRAINSTORMING: Socratic Q&A "What providers do you need?" "What about existing users?" "Security requirements?"
2. GIT WORKTREE: Create isolated environment $ git worktree add ../auth-feature -b feature/oauth2
3. WRITING PLANS: 2-5 minute steps Plan includes: - Step 1: Write failing test for OAuth2 interface - Step 2: Implement interface (minimal) - Step 3: Write tests for Google provider - Step 4: Implement Google provider - Step 5: Review and refactor
4. SUBAGENT DEV: ┌─────────────┐ │ Controller │ Reads plan, coordinates └──────┬──────┘ ▼ ┌─────────────┐ │ Implementer │ Writes code + tests └──────┬──────┘ ▼ ┌─────────────┐ │ Reviewer │ Objective code review └─────────────┘
5. FINISHING BRANCH: - Merge to main - Create PR - Or discard if approach was wrongThe Trade-offs I Accept
After testing both, here’s my honest assessment:
OpenSpec Trade-offs I Accept:
- Manual testing discipline - I trust my team to write tests (
/opsx:verifyflags gaps) - Single-agent limitations - I can still use a subagent harness manually if needed
- Self-review bias - We have human code review processes
Superpowers Trade-offs I Accept:
- No spec knowledge base - We document in wiki instead, or pair with OpenSpec (see below)
- Higher token costs, mitigated - v6.0+ roughly halved per-run overhead vs early versions
- Harness choice, not lock-in - We commit to one of the eight supported harnesses, not one vendor
Using Them Together
These two frameworks aren’t mutually exclusive, and as of 2026 the community is actively layering them:
- OpenSpec owns the spec/artifact layer: proposals, design, delta specs,
/opsx:sync,/opsx:verify, Stores, and the audit trail. - Superpowers owns the execution discipline: git worktree isolation, mandatory TDD, subagent review, and the controller/implementer/reviewer loop.
In practice you let OpenSpec define what and why (the deltas and the archived rationale), then hand each task to a Superpowers plan that enforces how (failing test → implementation → refactor → reviewer). The coupling point is the tasks list: OpenSpec generates it, Superpowers consumes it as input to its brainstorm/plan pipeline. Teams running this combo report keeping OpenSpec’s decision traceability for compliance while getting Superpowers’ execution quality on the actual code path—without double tooling.
My Final Recommendation
Here’s the decision framework I now use:
IF project_type == "enterprise_compliance": USE OpenSpec REASON: Audit trails and spec management are non-negotiable
ELIF project_type == "greenfield" AND harness IN [ "claude-code", "cursor", "codex-cli", "opencode", "copilot-cli", "kimi-code", "pi", "antigravity"]: USE Superpowers REASON: TDD enforcement + objective review = higher quality
ELIF team_size > 10 AND need_spec_knowledge_base: USE OpenSpec REASON: Specs organized by capability scale better (Stores help)
ELIF testing_requirement == "strict" AND budget != "tight": USE Superpowers REASON: Mandatory TDD pays for itself in bug reduction
ELIF need_both_audit_trail AND strict_tdd: USE OpenSpec + Superpowers (layered) REASON: OpenSpec for spec/audit, Superpowers for execution
ELSE: EVALUATE based on: 1. Harness capabilities (subagent support? which of the 8+?) 2. Team discipline (can they self-enforce TDD?) 3. Long-term maintenance needs (spec queries? brownfield?)Related Knowledge
If you’re exploring spec-driven development, you might also want to understand:
- Context-Driven Development: How to provide AI assistants with the right context
- Multi-Agent Orchestration: Patterns for coordinating multiple AI agents
- Test-Driven AI Development: Strategies for maintaining quality with AI coding
- Spec-First API Design: Building APIs from specifications
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
- 👨💻 OpenSpec - Spec-Driven Change Management
- 👨💻 Superpowers - Multi-Agent Development Workflow
- 👨💻 2026 AI Specification Frameworks Compared: OpenSpec, Spec Kit, Superpowers, BMAD & GSD
- 👨💻 superpowers and sdd introduction
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
The choice between OpenSpec and Superpowers isn’t about which is “better” - it’s about which problem you’re solving. OpenSpec solves the “why did we make this change?” problem. Superpowers solves the “is this code correct?” problem. Pick the framework that addresses your team’s pain points—or layer them when you need both traceability and TDD quality—and you’ll see immediate benefits.
Comments