OpenSpec vs Superpowers: Spec Generation and Implementation Compared

TL;DR

• OpenSpec (Fission AI, MIT, npm CLI @fission-ai/openspec) is a spec artifact system: living specs, per-change folders, delta specs, and /opsx:* workflows backed by a CLI that skills query for structured state.
• Superpowers (Jesse Vincent / Prime Radiant, MIT, plugin) is a methodology enforcement layer: auto-triggering skills that shape how the agent brainstorms, plans, implements (TDD), reviews, and finishes branches — without prescribing a repo spec layout.
• They solve different failure modes. OpenSpec keeps requirements from drifting out of chat into durable, mergeable specs. Superpowers keeps agents from skipping design, tests, reviews, and worktree hygiene.
• Spec generation: OpenSpec produces structured artifacts (proposal.md, delta spec.md, design.md, tasks.md) under openspec/changes/. Superpowers produces conversational design chunks and a micro-task plan via the brainstorming and writing-plans skills — not a formal spec tree unless you add one.
• Implementation: OpenSpec’s /opsx:apply walks tasks.md and updates checkboxes. Superpowers dispatches subagent-driven-development or executing-plans, enforces RED/GREEN TDD, and runs two-stage review (spec compliance, then code quality).
• They can stack. OpenSpec for what to build and traceability; Superpowers for how the agent executes with discipline. Neither replaces the other by default.

What You Will Learn Here

• What OpenSpec and Superpowers each optimize for — and why they are not direct substitutes
• A feature-by-feature comparison of built-in workflows, artifacts, and agent surfaces
• How spec generation differs: structured delta specs vs conversational design + plans
• How implementation differs: task-driven apply vs TDD + subagent/review pipelines
• Platform caveats (especially Cursor limitations for Superpowers subagents)
• A decision table for when to pick one, the other, or both
• A concrete example routing the same feature through each toolkit
• How to use the Spec workflow picker sidebar to jump between all three-tool comparisons on this site

On July 14, 2026, I reviewed the current OpenSpec docs (opsx.md, workflows.md, commands.md, README), npm metadata for @fission-ai/openspec@1.6.0, the Superpowers README and release v6.1.1 (July 2, 2026), Superpowers skill files (writing-plans, executing-plans, subagent-driven-development), release notes, and Jesse Vincent’s original Superpowers announcement. Comparative conclusions about team fit and combining the tools are editorial inference unless tied to a primary source.

Why These Two Tools Show Up Together

Both projects landed in the same conversation window (late 2025 – mid 2026) as answers to the same headline problem: AI coding assistants move fast, but process collapses when everything lives in chat.

They diverge on the cure:

OpenSpec compares itself to Spec Kit and Kiro in its README. Superpowers compares itself to ad-hoc agent coding in its README and launch post. They are adjacent layers, not the same product category — which is why a side-by-side review is useful.

                    ┌─────────────────────────────────────┐
                    │         Your coding agent           │
                    └─────────────────┬───────────────────┘
                                      │
              ┌───────────────────────┴───────────────────────┐
              │                                               │
              ▼                                               ▼
   ┌──────────────────────┐                    ┌──────────────────────┐
   │      Superpowers     │                    │       OpenSpec       │
   │  HOW the agent works │                    │  WHAT you're building │
   │  TDD, reviews,       │                    │  specs, deltas,       │
   │  worktrees, subagents│                    │  archive, sync        │
   └──────────────────────┘                    └──────────────────────┘
              │                                               │
              └───────────────────────┬───────────────────────┘
                                      ▼
                           Application code + tests

Side-by-Side Setup

OpenSpec

npm install -g @fission-ai/openspec@latest
cd your-repo
openspec init
# optional: openspec init --tools cursor,claude
# optional: openspec config profile && openspec update   # expanded workflows

After init, OpenSpec creates openspec/specs/, openspec/changes/, optional openspec/config.yaml, and harness-specific skills/commands (for example .cursor/skills/openspec-propose/SKILL.md and .cursor/commands/opsx-propose.md).

Superpowers

In Cursor Agent chat:

/add-plugin superpowers

Or install from the plugin marketplace in Claude Code, Codex, Factory Droid, Copilot CLI, OpenCode, Pi, Kimi Code, and others. No repo init step — the plugin injects the using-superpowers bootstrap at session start.

OpenSpec entry points                 Superpowers entry points
─────────────────────                 ────────────────────────
Terminal: openspec init               Plugin: /add-plugin superpowers
Terminal: openspec list|validate      Automatic: skills trigger on context
AI chat:  /opsx:propose               Implicit: "help me build X" → brainstorming
AI chat:  /opsx:apply                 Implicit: approved design → writing-plans → implement

Built-In Features: Side-by-Side

Core workflow (source-backed)

Agent surface

OpenSpec skills are not decorative prompts. They query the CLI for structured state before writing one artifact at a time:

User: /opsx:continue
  │
  ├─► openspec status --change add-dark-mode --json
  ├─► openspec instructions specs --change add-dark-mode --json
  ├─► read dependency artifacts (proposal.md, …)
  └─► write ONE artifact (e.g. delta spec)

Superpowers inverts that model: the agent checks for applicable skills before every task, and skills encode mandatory behavior (TDD, review gates, worktree setup).

Default artifact graph (OpenSpec spec-driven schema)

OpenSpec’s default schema produces four linked artifact types:

proposal ──→ specs ──→ design ──→ tasks ──→ /opsx:apply

Delta specs use ADDED / MODIFIED / REMOVED sections so brownfield changes stay auditable. On archive, deltas merge into openspec/specs/<capability>/spec.md.

Superpowers’ default chain (from the README):

brainstorming ──→ using-git-worktrees ──→ writing-plans
       │
       └──► subagent-driven-development | executing-plans
                    │
                    ├── test-driven-development (during each task)
                    ├── requesting-code-review (between tasks)
                    └── finishing-a-development-branch

The Superpowers plan emphasizes 2–5 minute tasks with exact file paths, verification steps, and enough detail that a “junior engineer with poor taste” could execute it — a different granularity than OpenSpec’s tasks.md, which tracks implementation checklist items tied to specs.

Spec Generation: Where They Actually Differ

This is the heart of the comparison for architects.

OpenSpec: specs as durable repo artifacts

OpenSpec treats specifications as first-class, versioned files:

• Main specs describe current system behavior (openspec/specs/).
• Change folders hold proposal, delta specs, design, and tasks (openspec/changes/<name>/).
• Archive moves completed changes to openspec/changes/archive/ and optionally syncs deltas into main specs.
• Project config (openspec/config.yaml) injects stack context and per-artifact rules (for example Given/When/Then scenarios).

Advantages (source-backed + inference):

Tradeoffs (inference):

• Requires init, conventions, and occasional openspec update after upgrades.
• Spec quality still depends on model + templates — OpenSpec opens templates for editing, but someone has to maintain them.

Superpowers: specs as negotiated conversation → plan

Superpowers generates specs through skills, not a fixed directory schema:

1. brainstorming — Refines intent via questions; presents design in short sections for human approval.
2. writing-plans — Converts approved design into a granular implementation plan (default save path: docs/superpowers/plans/).

As of Superpowers v6.x, brainstorming and writing-plans use inline self-review checklists during spec/plan creation rather than subagent review loops — faster, but still not a mergeable delta-spec model.

There is no built-in delta-spec merge, capability-oriented spec tree, or /opsx:sync equivalent. The plan becomes the implementation contract for that session/branch.

Advantages (source-backed + inference):

Tradeoffs (inference):

• Less durable cross-session requirements unless you manually commit design/plan files.
• Harder for multi-team “source of truth” spec consumption without adding OpenSpec or similar.
• Skill behavior varies by harness (see platform notes below).

Spec generation comparison table

Implementation: Where Discipline Comes From

OpenSpec /opsx:apply

From OpenSpec’s commands docs, /opsx:apply:

• Reads tasks.md and identifies incomplete items.
• Implements tasks one by one — code, files, tests as needed.
• Checks off completed tasks.
• Can update artifacts when implementation reveals spec gaps (fluid workflow).

OpenSpec does not centrally enforce TDD, subagent dispatch, or two-stage review. Those depend on your agent rules, model, and any overlapping plugins.

Superpowers implementation stack

Superpowers treats implementation as a gated pipeline:

The README claims multi-hour autonomous runs that stay on-plan — that is an author assertion, not a benchmark. Treat it as design intent, not a SLA.

Platform caveat: harness subagent support

Superpowers treats subagent orchestration as a harness capability, not something every plugin install gets equally.

From Superpowers v6.x release notes and the executing-plans skill (July 2026):

• Subagent-capable harnesses (explicitly listed): Claude Code, Codex CLI, Codex App, Copilot CLI.
• subagent-driven-development is required on those harnesses after plan approval.
• executing-plans is reserved for harnesses without subagent capability and tells the user that Superpowers works better on subagent-capable platforms.

Cursor is supported as a plugin, but it is not listed among Superpowers’ subagent-capable harnesses as of v6.1.1. On Cursor, expect executing-plans (inline task execution with checkpoints) rather than the full subagent dispatch loop — unless Superpowers later adds Cursor to its subagent-capable list.

OpenSpec’s /opsx:apply is harness-agnostic — it is instructions plus task files, not subagent infrastructure.

Extensibility and Customization

OpenSpec

• openspec/config.yaml — project context + per-artifact rules.
• schema.yaml + templates — custom artifact graphs (community schemas catalog exists).
• Workflow profiles — core (propose/explore/apply/sync/archive) vs expanded (new/continue/ff/verify/bulk-archive/onboard).
• Stores (beta) — standalone planning repos shared across code repos.

OpenSpec’s OPSX docs explicitly frame customization as editing templates/schemas without waiting for package releases.

Superpowers

• Skills library — 14 documented skills spanning testing, debugging, collaboration, meta.
• writing-skills — meta-skill for authoring and pressure-testing new skills.
• Plugin updates — often automatic per harness.
• Contribution policy — README notes they do not generally accept new upstream skills; changes must work across all supported agents.

Superpowers optimizes for behavioral consistency. OpenSpec optimizes for artifact flexibility.

When to Use Which

Editorial judgment: If you must pick one, choose OpenSpec when spec traceability and brownfield deltas are the bottleneck; choose Superpowers when agent discipline (TDD, reviews, worktrees) is the bottleneck.

Same Feature, Two Routes

Feature: Add article audio summary playback to an Astro devlog.

Route A — OpenSpec

/opsx:explore          → clarify delivery (inline player vs modal), scope caps
/opsx:propose article-audio-summary-pipeline
                       → proposal.md, delta specs (ui, generation, delivery),
                         design.md, tasks.md
/opsx:apply            → implement tasks; check off items
/opsx:archive          → sync deltas into openspec/specs/; archive change

Artifacts remain readable for the next engineer — including requirements the agent never re-derives from chat.

Route B — Superpowers

"Help me add audio summaries to articles"
  → brainstorming: questions on UX, storage, generation API
  → design sections approved
  → using-git-worktrees: feat/article-audio branch
  → writing-plans: 2–5 min tasks with file paths + verification
  → executing-plans or subagent-driven-development
  → test-driven-development on each task
  → finishing-a-development-branch: PR or merge

You get strong implementation hygiene. Lasting requirements live wherever the skills wrote them — unless you adopt OpenSpec (or similar) for the spec layer.

Route C — Combined (inference)

OpenSpec: /opsx:propose + delta specs     ← WHAT + traceability
Superpowers: TDD + review skills         ← HOW with discipline

This is not an official integrated product — it is a practical stack many teams can assemble manually.

Stacking risks (inference): Both tools inject skills and behavioral rules. Without coordination, you may get duplicate planning phases (OpenSpec /opsx:propose plus Superpowers brainstorming) or conflicting git/worktree instructions. A practical pattern: use OpenSpec for artifact creation, then let Superpowers skills govern implementation hygiene only.

Advantages Summary

Sources

Primary sources consulted on July 14, 2026:

• OpenSpec README — philosophy, quick start, comparisons, MIT license
• OpenSpec OPSX workflow — fluid actions, artifacts, config, schemas
• OpenSpec workflows — core vs expanded profiles
• OpenSpec commands — /opsx:* behavior including apply and archive
• npm @fission-ai/openspec — version 1.6.0 at time of writing
• Superpowers README — skills library, workflow, installation, v6.1.1 release
• Superpowers RELEASE-NOTES — v6.x harness subagent behavior, Cursor plugin support
• Superpowers writing-plans skill — plan format, default save path, execution handoff
• Superpowers executing-plans skill — subagent-capable platform list
• Superpowers subagent-driven-development skill — two-stage review model
• Superpowers launch post — brainstorm → plan → implement origin, skills rationale (October 9, 2025)
• OpenSpec supported tools — tool IDs and generated skill names

Related reading in this devlog:

• OpenSpec vs GitHub Spec Kit — compares two spec artifact frameworks (use the Spec workflow picker in the article sidebar)
• Advanced OpenSpec: Expanded Workflows — /opsx:verify, custom schemas, profiles
• Replace Plan Mode with OpenSpec — when structured specs beat IDE plan mode