OpenSpec vs GitHub Spec Kit: A Side-by-Side Review of Spec-Driven Development

TL;DR

• OpenSpec (Fission AI, MIT, npm CLI) and GitHub Spec Kit (GitHub, Python specify CLI) both put specifications at the center of AI-assisted delivery, but they optimize for different failure modes.
• OpenSpec is brownfield-first, delta-spec oriented, and fluid: /opsx:propose → /opsx:apply → /opsx:archive, with living specs under openspec/specs/ and per-change folders under openspec/changes/.
• GitHub Spec Kit is phase-rich and platform-shaped: /speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement, with feature folders under specs/<feature>/.
• Skills vs commands: OpenSpec ships both agent skills (openspec-propose, openspec-apply-change, …) and slash commands (/opsx:*). Spec Kit primarily ships integration command files (.cursor/commands/speckit.*.md, etc.) and extends through extensions, presets, workflows, and bundles.
• Artifacts: OpenSpec emphasizes delta specs (ADDED/MODIFIED/REMOVED) merged on archive. Spec Kit emphasizes feature-scoped PRD + plan + contracts + tasks, often with extra validation commands.
• Token usage: neither project publishes official token benchmarks. My inference (labeled below): OpenSpec tends to be cheaper for small iterative changes; Spec Kit tends to spend more tokens up front on gates and supporting documents, which can save rework on large or regulated features.
• Extensibility: OpenSpec customizes through editable schema.yaml, templates, and openspec/config.yaml. Spec Kit customizes through a catalog ecosystem (105+ community extensions as of May 27, 2026), presets, workflows, and bundles.

What You Will Learn Here

• What OpenSpec and GitHub Spec Kit each optimize for
• How their skills/commands differ in practice
• A side-by-side view of workflows and generated artifacts
• An inferred token model you can use for planning (with clear limits)
• How each toolkit extends, and when to pick one over the other
• A concrete example of the same feature routed through both toolkits

On July 1, 2026, I reviewed the current OpenSpec docs (OPSX workflow, supported tools, getting started), the GitHub Spec Kit docs and spec-driven.md, npm registry metadata for @fission-ai/openspec@1.5.0, and this repo’s existing Spec Kit articles. Comparative conclusions about token cost and team fit are editorial inference unless explicitly tied to a primary source.

Why These Two Tools Show Up Together

Both projects claim the same headline problem: AI coding assistants move fast, but requirements drift when they live only in chat history.

They diverge on the cure:

OpenSpec’s README even names Spec Kit directly as the “thorough but heavyweight” alternative. GitHub’s docs list OpenSpec among community “friend projects.” That makes a direct comparison fair game.

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   # enable expanded workflows

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

GitHub Spec Kit

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
cd your-repo
specify init --here --integration cursor-agent
# optional: specify extension add git

After init, Spec Kit creates .specify/, templates, scripts, and integration files such as .cursor/commands/speckit.specify.md.

OpenSpec entry points                 Spec Kit entry points
─────────────────────                 ─────────────────────
Terminal: openspec init               Terminal: specify init
Terminal: openspec list|validate      Terminal: specify check|version
AI chat:  /opsx:propose               AI chat:  /speckit.specify
AI chat:  /opsx:apply                 AI chat:  /speckit.implement

Skills and Commands: Not the Same Abstraction

This is the most confusing comparison point, especially for PMs who hear “skills” used loosely.

OpenSpec: skills and slash commands

OpenSpec’s supported-tools doc describes a dual delivery model:

1. Skills — openspec-propose, openspec-explore, openspec-apply-change, openspec-sync-specs, openspec-archive-change, …
2. Commands — /opsx:propose, /opsx:apply, /opsx:archive, …

Default core profile workflows: propose, explore, apply, sync, archive.

Expanded profile adds: new, continue, ff, verify, bulk-archive, onboard.

Skills are not decorative. OPSX skills query the CLI for structured state (openspec status --json, openspec instructions --json) before generating one artifact at a time. That is a different architecture from a static prompt file.

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)

GitHub Spec Kit: integration commands (+ platform primitives)

Spec Kit’s primary agent surface is integration command files installed per agent — for Cursor, files like /speckit.specify, /speckit.plan, /speckit.tasks.

The official core command set documented in spec-driven.md and the Spec Kit docs:

Spec Kit does not ship OpenSpec-style per-workflow skill folders by default. Instead, extensibility lives in extensions (new commands), presets (template/command overrides), workflows (multi-step automation), and bundles (curated stacks).

Practical translation for mixed teams

Workflow Comparison

OpenSpec OPSX (default core path)

/opsx:explore (optional)
        │
        ▼
/opsx:propose ──► proposal.md + delta specs + design.md + tasks.md
        │
        ▼
/opsx:apply ─────► implement tasks (edit artifacts anytime)
        │
        ▼
/opsx:sync ──────► optional delta merge prep
        │
        ▼
/opsx:archive ───► merge ADDED/MODIFIED/REMOVED into openspec/specs/

Design choice: dependencies are enablers, not hard phase gates. You can update specs during implementation without “leaving” a phase.

GitHub Spec Kit (documented core path)

/speckit.constitution
        │
        ▼
/speckit.specify ──► spec.md (+ feature branch / numbered folder)
        │
        ▼
/speckit.clarify ──► resolved questions in spec artifacts
        │
        ▼
/speckit.plan ─────► plan.md + research/data-model/contracts/quickstart (varies)
        │
        ▼
/speckit.tasks ────► tasks.md with [P] parallel markers
        │
        ▼
/speckit.implement ► code + tests
        │
        ▼
/speckit.analyze ──► optional consistency pass

Design choice: each phase produces a Markdown artifact that feeds the next. Extra commands exist because Spec Kit assumes teams want explicit quality gates.

ASCII overlay: same story, different choreography

                    OPEN SPEC                         SPEC KIT
                    ─────────                         ────────

Intent capture      proposal.md                       spec.md (+ constitution context)
Behavior contract   delta specs (ADD/MOD/REM)         user stories + acceptance in spec.md
Technical design    design.md                         plan.md + contracts/data-model/…
Execution map       tasks.md                          tasks.md
Implementation      /opsx:apply                       /speckit.implement
Promotion to canon  /opsx:archive → openspec/specs/   merge feature branch / team policy

For brownfield work, OpenSpec’s delta model is the sharper distinction. Spec Kit can document current behavior, but its happy path still reads like feature delivery, not spec mutation tracking.

Generated Artifacts Compared

OpenSpec artifact tree

openspec/
├── config.yaml                 # optional project context + per-artifact rules
├── specs/                      # canonical behavior library
│   └── auth/spec.md
└── changes/
    └── add-2fa/
        ├── proposal.md
        ├── design.md
        ├── tasks.md
        └── specs/auth/spec.md  # delta: ADDED/MODIFIED/REMOVED sections

Delta excerpt (from OpenSpec getting started):

## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.

#### Scenario: OTP required
- GIVEN a user with 2FA enabled
- WHEN the user submits valid credentials
- THEN an OTP challenge is presented

On archive, OpenSpec merges deltas into openspec/specs/ and moves the change folder to openspec/changes/archive/.

Spec Kit artifact tree

.specify/                       # tooling, templates, scripts
specs/
└── 042-tenant-sso/
    ├── spec.md
    ├── plan.md
    ├── tasks.md
    ├── research.md             # common after /speckit.plan
    ├── data-model.md
    ├── quickstart.md
    └── contracts/              # API/event contracts
        └── ...

Spec Kit’s /speckit.plan explicitly targets a richer artifact bundle than a single design doc. /speckit.tasks reads plan.md and optional contracts/models to derive parallelizable work.

Artifact comparison table

Token Usage: What We Can and Cannot Claim

Fact: neither OpenSpec nor GitHub Spec Kit publishes official token benchmarks as of July 1, 2026.

Inference: the tables below are a planning model, not measured data. Treat numbers as order-of-magnitude guides for comparing relative cost, not invoices.

What drives token cost in both tools

1. Number of agent turns (each slash command is usually at least one generation pass)
2. Size of artifacts injected into the next command (constitution, spec, plan, contracts, repo context)
3. Breadth of output (one design doc vs plan + contracts + research)
4. Re-work loops (clarify/analyze/archive-sync vs fluid artifact edits)

Relative cost model (editorial inference)

Example token budget sketch (single feature, one agent session)

Assume ~1x = one medium agent call reading prior artifacts.

PM takeaway: Spec Kit often front-loads tokens into documents that humans review. OpenSpec often spends fewer tokens per change if your living specs are already accurate.

Engineering takeaway: OpenSpec’s incremental /opsx:continue path reduces blast radius when a single artifact is wrong. Spec Kit’s /speckit.analyze path reduces blast radius when cross-document drift is the risk.

Extensibility Compared

OpenSpec: schema-first customization

OpenSpec OPSX exposes customization in-repo:

• schema.yaml — define artifacts and dependency graph
• templates/*.md — edit generation instructions without waiting for a release
• openspec/config.yaml — inject shared context (50KB limit) and per-artifact rules

# openspec/config.yaml (illustrative)
context: |
  Tech stack: TypeScript, Astro, React islands
rules:
  specs:
    - Use Given/When/Then format for scenarios
  proposal:
    - Include rollback plan

Power users can add workflows via openspec config profile and regenerate skills/commands with openspec update.

Strength: fast local iteration, git-reviewable prompt/schema changes.

Gap: no first-party multi-repo catalog equivalent to Spec Kit’s extension marketplace (OpenSpec Stores are beta for cross-repo planning).

GitHub Spec Kit: platform-first customization

Spec Kit’s docs describe four extension layers:

Official docs cite 105 community extensions (60+ authors) and 22 presets as of May 27, 2026. Community catalog count may drift; pin versions in production repos.

Strength: shareable, discoverable packages across repos and orgs.

Gap: more moving parts; extension quality varies (see GitHub Spec Kit community extensions).

Extensibility decision matrix

Need to tweak prompts this afternoon?
  └─► OpenSpec templates/schema

Need org-wide approved workflow packages?
  └─► Spec Kit presets + bundles + org catalog

Need a new gate (security, QA, architecture)?
  └─► Spec Kit extension (or OpenSpec custom schema artifact)

Need agent-agnostic skills across many tools?
  └─► OpenSpec skills generation

Example: “Add tenant SSO” Through Both Toolkits

Same feature, different choreography.

OpenSpec path

/opsx:explore
  "We need SAML/OIDC tenant SSO for enterprise customers."

/opsx:propose add-tenant-sso
  creates openspec/changes/add-tenant-sso/
    proposal.md
    specs/auth/spec.md      # ADDED requirements + scenarios
    design.md               # IdP metadata, session bridging
    tasks.md

/opsx:apply
  implement tasks; update design if IdP discovery differs

/opsx:archive
  merge delta into openspec/specs/auth/spec.md

Spec Kit path

/speckit.specify Add tenant SSO for enterprise accounts with SAML and OIDC
  creates specs/00N-tenant-sso/spec.md (+ feature branch)

/speckit.clarify
  resolve IdP admin vs self-serve, session lifetime, logout behavior

/speckit.plan
  SAML library choice, metadata storage, multi-tenant routing

/speckit.tasks
  tasks.md with [P] markers for parallel backend/frontend work

/speckit.implement

/speckit.analyze
  cross-check spec ↔ plan ↔ tasks ↔ code

PM view: Spec Kit gives more scheduled review points. OpenSpec gives a shorter path if SSO requirements already live in openspec/specs/auth/spec.md from prior work.

Engineer view: Spec Kit’s contracts/ folder shines when SSO touches many services. OpenSpec’s delta merge shines when SSO is an evolution of an existing auth spec.

How to Choose (Engineers and PMs)

                         START
                           │
           ┌───────────────┴───────────────┐
           │ Do specs need to stay live     │
           │ after shipping (brownfield)?   │
           └───────────────┬───────────────┘
                     YES   │   NO
                      ┌────┴────┐
                      ▼         ▼
                 OpenSpec    Either works;
                 strong fit  Spec Kit greenfield OK
                      │
                      ▼
           ┌───────────────────────┐
           │ Need catalog-based     │
           │ org extensions?        │
           └───────────┬───────────┘
                 YES   │   NO
                  ┌────┴────┐
                  ▼         ▼
              Spec Kit   OpenSpec schema
              platform   templates likely enough
                  │
                  ▼
           ┌───────────────────────┐
           │ Regulated / large cross- │
           │ artifact consistency?    │
           └───────────┬───────────┘
                 YES   │   NO
                  ┌────┴────┐
                  ▼         ▼
           Spec Kit      OpenSpec core
           + analyze     + optional verify

You can also hybridize: OpenSpec for living domain specs, Spec Kit for one-off greenfield spikes. That adds process tax — only do it with explicit ownership of which directory is canonical.

Risks and Honest Limits

• Hype vs production: both tools assume capable coding agents. Neither removes human judgment on product trade-offs.
• OpenSpec comparisons in its README are marketing-adjacent. Validate against your repo before trusting “lighter/heavier” claims.
• Spec Kit’s branch-first flow can fight git worktrees and polyrepos; see integrating Spec Kit in existing repos.
• Token table in this article is inferred. Measure your own runs if cost matters.
• Overlap with this devlog: existing articles go deep on Spec Kit operations (phase-by-phase models, feedback handling). This piece is the OpenSpec-facing comparison those articles did not cover.

Sources

Primary:

• Fission AI, OpenSpec repository — README, MIT license, comparison note vs Spec Kit (accessed July 1, 2026)
• Fission AI, OpenSpec OPSX workflow doc — actions, schemas, dependency graph (accessed July 1, 2026)
• Fission AI, OpenSpec getting started — directory layout, delta spec format, archive behavior (accessed July 1, 2026)
• Fission AI, OpenSpec supported tools — skills/commands matrix (accessed July 1, 2026)
• npm, @fission-ai/openspec@1.5.0 — release date June 28, 2026 (accessed July 1, 2026)
• OpenSpec, openspec.dev — product positioning, brownfield-first philosophy (accessed July 1, 2026)
• GitHub, Spec Kit repository — core SDD flow (accessed July 1, 2026)
• GitHub, Spec Kit documentation site — extensions/presets/workflow counts, last updated May 27, 2026 (accessed July 1, 2026)
• GitHub, Specification-Driven Development (spec-driven.md) — /speckit.* commands and artifact families (accessed July 1, 2026)
• GitHub Blog, Spec-driven development with AI — launch narrative (accessed July 1, 2026)

Related reading on this site:

• How to Integrate GitHub Spec Kit into Existing Repositories with Cursor
• GitHub Spec Kit Community Extensions
• A Phase-by-Phase Model Strategy for GitHub Spec Kit in 2026