OpenSpec Spec-Driven Superpowers — Summary

OpenSpec Spec-Driven Superpowers is an OpenSpec schema that bridges OpenSpec's change-lifecycle control plane with the superpowers behavioral framework's execution discipline. It adds a review.md readiness gate artifact, a plan.md execution driver, and optional advanced execution modes (delegation, parallelization, git-worktree isolation) to the standard spec-driven workflow — without modifying the default OpenSpec command surface or requiring users to maintain a CLI fork. The schema supports a "schema-only" fallback mode when superpowers skills are unavailable, preserving artifact continuity. With 14 stars and documentation covering adoption, migration, and mode selection, it is the most structured cross-framework integration in the OpenSpec ecosystem.

Compared to seeds: closest to openspec (same CLI) combined with superpowers (same skill set). The key architectural delta over both is the review.md readiness gate — a first-class pre-implementation approval document that records readiness decision, blockers, validation focus, and optional execution/verification/delegation/parallelization modes in a structured format. No seed has a dedicated readiness-gate artifact as a schema node.

OpenSpec Spec-Driven Superpowers — Overview

Origin

Created by GitHub user Veath. Published March 2026. Explicitly integrates two external projects:

• OpenSpec (https://github.com/Fission-AI/OpenSpec) — control plane
• superpowers (https://github.com/obra/superpowers) — execution discipline

Philosophy

From the README:

"Default spec-driven is intentionally light. That is usually good, but on cross-cutting or high-risk work teams often need more structure: a real readiness gate before implementation, a real execution plan instead of a single coarse checklist, stronger apply-time discipline, stronger verification and review loops, and optional delegation, parallelization, worktree isolation, and finish-ready rules."

The model:

"OpenSpec owns the control plane. superpowers upgrades the working discipline."

Key design decision: no parallel wrapper command set, no patching of OpenSpec default skills. Teams keep the /opsx:* surface. The schema adds discipline via artifact instructions that prefer superpowers skills.

Graceful Degradation

"If a preferred superpowers capability is unavailable, the workflow falls back to the same artifact paths and structure. You do not lose artifact continuity, and the workflow does not stall just because a runtime capability is missing."

Two modes:

• Schema-only mode: works without superpowers installed; schema instructions provide the structure
• Full instruction-bridge mode: requires both OpenSpec + superpowers; schema instructions invoke superpowers skills by name

Preferred superpowers Skills

• brainstorming
• writing-plans
• executing-plans
• test-driven-development
• verification-before-completion
• systematic-debugging
• requesting-code-review
• receiving-code-review
• subagent-driven-development
• dispatching-parallel-agents
• using-git-worktrees
• finishing-a-development-branch

OpenSpec Spec-Driven Superpowers — Architecture

Distribution

• Type: standalone-repo (schema + docs + examples)
• Install: copy schemas/spec-driven-superpowers/ into project OpenSpec schemas directory
• Activation: schema: spec-driven-superpowers in openspec/config.yaml
• Profile switcher script (scripts/switch-openspec-config.mjs) for switching between default spec-driven and spec-driven-superpowers

Runtime Requirements

• OpenSpec CLI >= 1.0.0
• Node.js >= 20 (via OpenSpec)
• superpowers installed (optional, for full instruction-bridge mode)

Directory Structure

openspec-spec-driven-superpowers/
├── README.md
├── LICENSE
├── package.json
├── docs/
│   ├── adoption.md
│   ├── modes.md
│   └── migration.md
├── examples/
│   └── basic-adoption/
├── profiles/
│   ├── config.spec-driven.yaml.example
│   └── config.spec-driven-superpowers.yaml.example
├── schemas/
│   └── spec-driven-superpowers/
│       ├── schema.yaml
│       └── templates/
│           ├── proposal.md
│           ├── spec.md
│           ├── design.md
│           ├── review.md
│           ├── tasks.md
│           └── plan.md
├── scripts/
│   └── switch-openspec-config.mjs
└── specs/

Main Artifacts

Profile Switching

node scripts/switch-openspec-config.mjs spec-driven
node scripts/switch-openspec-config.mjs spec-driven-superpowers

Or via npm scripts added by adopters:

{
  "scripts": {
    "openspec:profile:spec-driven": "node scripts/switch-openspec-config.mjs spec-driven",
    "openspec:profile:spec-driven-superpowers": "node scripts/switch-openspec-config.mjs spec-driven-superpowers"
  }
}

OpenSpec Spec-Driven Superpowers — Components

Schema Artifacts (6)

Review Artifact Structure

The review.md artifact has a defined section schema (from schema instruction):

Always required sections:

• Readiness Decision
• Blocked By
• Validation Focus
• Key Risks

Optional mode sections (only when justified):

• Execution Mode
• Verification Mode
• Debug Mode
• Review Request / Review Scope / Review Focus / Review Status
• Delegation Mode
• Parallelization Mode
• Worktree Mode
• Branch Finish Mode

Companion Files (not schema artifacts)

Scripts

Commands/Skills/Hooks

None added by this repo. Standard OpenSpec command surface (/opsx:*).

Templates (6)

proposal.md, spec.md, design.md, review.md, tasks.md, plan.md — all in schemas/spec-driven-superpowers/templates/

OpenSpec Spec-Driven Superpowers — Uniqueness

differs_from_seeds

Closest seeds: openspec (same CLI, same command surface) and superpowers (same skill set). The architectural delta from openspec is the addition of review.md as a structured readiness-gate artifact between design and implementation — not present in the default OpenSpec schema or any other seed. The delta from superpowers is that execution discipline is encoded in a schema artifact graph (not just free-floating skills), and OpenSpec owns the state machine. No seed achieves this precise combination: spec-driven artifact lifecycle + behavioral skill invocation + per-change execution mode selection. The closest is BMAD-method which uses persona skills to control execution quality, but BMAD does not have a dedicated readiness gate artifact and is not built on OpenSpec.

Positioning

The "best of both worlds" integration: OpenSpec's predictable artifact lifecycle (proposal → specs → design → tasks → apply → archive) plus superpowers' execution quality (brainstorming, TDD, verification, parallel dispatch, worktree isolation). The review.md gate is the unique addition — it forces an explicit readiness decision and records the execution mode (delegation, parallelization, worktrees) that will be used for implementation, rather than leaving those choices implicit.

Key Differentiator

The review.md section schema is the most structured pre-implementation gate in the corpus. It distinguishes:

• Required sections (readiness decision, blockers, validation focus, risks)
• Optional mode sections (execution/verification/delegation/parallelization/worktree modes)

This is "structured decision logging" — the document records both the decision and the mode configuration that flows into the plan.

Observable Failure Modes

1. Schema-only vs. instruction-bridge confusion: teams using schema-only mode won't get the superpowers skill benefits but may not realize it.
2. review.md maintenance burden: on small changes, the review gate adds overhead without clear value — the README recommends staying on default spec-driven for small changes, but teams may apply the schema uniformly.
3. plan.md / tasks.md consistency: if plan changes task boundaries but tasks.md is not updated, downstream resume attempts will find inconsistent state.
4. Superpowers version drift: superpowers skill names in the schema instructions may change if the superpowers repo evolves.