OpenSpec vs GitHub Spec Kit: una comparación lado a lado del desarrollo guiado por especificaciones

Resumen

• OpenSpec (Fission AI, MIT, CLI de npm) y GitHub Spec Kit (GitHub, CLI de Python specify) ponen las especificaciones en el centro de la entrega asistida por IA, pero buscan prevenir distintos tipos de fallas.
• OpenSpec prioriza proyectos existentes, se basa en diferencias entre especificaciones y es flexible: /opsx:propose → /opsx:apply → /opsx:archive, con especificaciones vivas en openspec/specs/ y carpetas por cambio en openspec/changes/.
• GitHub Spec Kit tiene numerosas fases y una estructura de plataforma: /speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement, con carpetas por funcionalidad en specs/<feature>/.
• Skills vs comandos: OpenSpec incluye ambos: skills para agentes (openspec-propose, openspec-apply-change, …) y comandos de barra (/opsx:*). Spec Kit incluye principalmente archivos de comandos de integración (.cursor/commands/speckit.*.md, etc.) y se amplía mediante extensiones, presets, workflows y bundles.
• Artefactos: OpenSpec pone el énfasis en especificaciones delta (ADDED/MODIFIED/REMOVED) que se integran al archivar. Spec Kit pone el énfasis en PRD + plan + contratos + tareas para cada funcionalidad, a menudo con comandos de validación adicionales.
• Uso de tokens: ninguno de los dos proyectos publica benchmarks oficiales de tokens. Mi inferencia, identificada como tal más adelante: OpenSpec suele ser más económico para cambios iterativos pequeños; Spec Kit suele gastar más tokens al principio en controles y documentos de apoyo, lo que puede evitar retrabajo en funcionalidades grandes o reguladas.
• Extensibilidad: OpenSpec se personaliza mediante schema.yaml, plantillas y openspec/config.yaml editables. Spec Kit se personaliza mediante un ecosistema de catálogos (105+ extensiones de la comunidad al May 27, 2026), presets, workflows y bundles.

Qué aprenderás aquí

• Qué busca optimizar cada herramienta: OpenSpec y GitHub Spec Kit
• En qué se diferencian sus skills/comandos en la práctica
• Una comparación lado a lado de los workflows y los artefactos generados
• Un modelo inferido de tokens que puedes usar para planificar, con límites claros
• Cómo se amplía cada conjunto de herramientas y cuándo elegir uno en lugar del otro
• Un ejemplo concreto de la misma funcionalidad implementada con ambos conjuntos de herramientas
• Cómo usar el selector Spec workflow picker de la barra lateral para comparar OpenSpec, Spec Kit y Superpowers a lo largo de este devlog

El July 1, 2026, revisé la documentación vigente de OpenSpec (workflow de OPSX, herramientas compatibles y guía de inicio), la documentación de GitHub Spec Kit y spec-driven.md, los metadatos del registro de npm para @fission-ai/openspec@1.5.0 y los artículos sobre Spec Kit que ya existen en este repositorio. Las conclusiones comparativas sobre el costo en tokens y la adecuación a cada equipo son inferencias editoriales, salvo que se atribuyan explícitamente a una fuente primaria.

Por qué estas dos herramientas suelen aparecer juntas

Ambos proyectos parten del mismo problema principal: los asistentes de código con IA avanzan rápido, pero los requisitos se desvían cuando solo existen en el historial del chat.

Difieren en la solución:

El README de OpenSpec incluso menciona a Spec Kit directamente como la alternativa «exhaustiva, pero pesada». La documentación de GitHub incluye a OpenSpec entre los «proyectos amigos» de la comunidad. Por eso, una comparación directa resulta pertinente.

Configuración lado a lado

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

Después de la inicialización, OpenSpec crea openspec/specs/, openspec/changes/, el archivo opcional openspec/config.yaml y skills/comandos específicos de cada herramienta (por ejemplo, .cursor/skills/openspec-propose/SKILL.md y .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

Después de la inicialización, Spec Kit crea .specify/, plantillas, scripts y archivos de integración como .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 y comandos: no son la misma abstracción

Este es el punto más confuso de la comparación, especialmente para los PMs que escuchan que se usa «skills» de manera imprecisa.

OpenSpec: skills y comandos de barra

La documentación de herramientas compatibles de OpenSpec describe un modelo de distribución dual:

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

Workflows del perfil principal predeterminado: propose, explore, apply, sync, archive.

El perfil ampliado agrega: new, continue, ff, verify, bulk-archive, onboard.

Las skills no son decorativas. Las skills de OPSX consultan el estado estructurado a través de la CLI (openspec status --json, openspec instructions --json) antes de generar un artefacto a la vez. Es una arquitectura distinta de la de un archivo de prompt estático.

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: comandos de integración (+ elementos de plataforma)

La interfaz principal de Spec Kit para los agentes son los archivos de comandos de integración instalados para cada agente: para Cursor, comandos como /speckit.specify, /speckit.plan y /speckit.tasks.

El conjunto oficial de comandos principales documentado en spec-driven.md y en la documentación de Spec Kit:

Spec Kit no incluye por defecto carpetas de skills por workflow al estilo de OpenSpec. En cambio, su extensibilidad reside en extensiones (comandos nuevos), presets (personalización de plantillas y comandos), workflows (automatización de varios pasos) y bundles (conjuntos seleccionados de componentes).

Implicaciones prácticas para equipos mixtos

Comparación de workflows

OpenSpec OPSX (flujo principal predeterminado)

/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/

Decisión de diseño: las dependencias son habilitadores, no barreras estrictas entre fases. Puedes actualizar las especificaciones durante la implementación sin «salir» de una fase.

GitHub Spec Kit (flujo principal documentado)

/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

Decisión de diseño: cada fase produce un artefacto Markdown que alimenta la siguiente. Existen comandos adicionales porque Spec Kit asume que los equipos quieren controles de calidad explícitos.

Comparación en ASCII: misma historia, distinta coreografía

                    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

Para el trabajo en proyectos existentes, el modelo de deltas de OpenSpec es la diferencia más marcada. Spec Kit puede documentar el comportamiento actual, pero su flujo ideal sigue pareciéndose más a la entrega de funcionalidades que al seguimiento de modificaciones de especificaciones.

Comparación de artefactos generados

Árbol de artefactos de OpenSpec

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

Fragmento de un delta (de la guía de inicio de OpenSpec):

## 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

Al archivar, OpenSpec integra los deltas en openspec/specs/ y mueve la carpeta del cambio a openspec/changes/archive/.

Árbol de artefactos de Spec Kit

.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
        └── ...

El comando /speckit.plan de Spec Kit apunta explícitamente a generar un conjunto de artefactos más amplio que un solo documento de diseño. /speckit.tasks lee plan.md y los contratos/modelos opcionales para derivar trabajo paralelizable.

Tabla comparativa de artefactos

Uso de tokens: qué podemos y qué no podemos afirmar

Hecho: ni OpenSpec ni GitHub Spec Kit publican benchmarks oficiales de tokens al July 1, 2026.

Inferencia: las tablas siguientes son un modelo de planificación, no datos medidos. Trata las cifras como una guía de orden de magnitud para comparar el costo relativo, no como facturas.

Qué determina el costo en tokens en ambas herramientas

1. Número de turnos del agente (cada comando de barra suele implicar al menos una pasada de generación)
2. Tamaño de los artefactos incorporados al siguiente comando (constitución, especificación, plan, contratos, contexto del repositorio)
3. Amplitud de la salida (un documento de diseño frente a un plan + contratos + investigación)
4. Ciclos de retrabajo (clarify/analyze/archive-sync frente a ediciones flexibles de artefactos)

Modelo de costo relativo (inferencia editorial)

Ejemplo estimado de presupuesto de tokens (una funcionalidad, una sesión de agente)

Supongamos que ~1x = una llamada mediana al agente que lee los artefactos anteriores.

Conclusión para PMs: Spec Kit suele invertir más tokens desde el principio en documentos que revisan las personas. OpenSpec suele gastar menos tokens por cambio si tus especificaciones vivas ya son precisas.

Conclusión para ingeniería: el flujo incremental /opsx:continue de OpenSpec reduce el alcance del impacto cuando un solo artefacto es incorrecto. El flujo /speckit.analyze de Spec Kit reduce el alcance del impacto cuando el riesgo es la desviación entre documentos.

Comparación de extensibilidad

OpenSpec: personalización basada en esquemas

OpenSpec OPSX permite personalizar el flujo dentro del repositorio:

• schema.yaml — definir artefactos y el grafo de dependencias
• templates/*.md — editar instrucciones de generación sin esperar una nueva versión
• openspec/config.yaml — incorporar contexto compartido (límite de 50KB) y reglas por artefacto

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

Los usuarios avanzados pueden agregar workflows mediante openspec config profile y regenerar skills/comandos con openspec update.

Fortaleza: iteración local rápida y cambios en prompts/esquemas que se pueden revisar en git.

Limitación: no hay un catálogo oficial para múltiples repositorios equivalente al marketplace de extensiones de Spec Kit (OpenSpec Stores está en beta para la planificación entre repositorios).

GitHub Spec Kit: personalización basada en plataforma

La documentación de Spec Kit describe cuatro capas de extensión:

La documentación oficial menciona 105 extensiones de la comunidad (60+ autores) y 22 presets al May 27, 2026. La cantidad del catálogo comunitario puede cambiar; fija las versiones en los repositorios de producción.

Fortaleza: paquetes que se pueden compartir y descubrir entre repositorios y organizaciones.

Limitación: más componentes en movimiento; la calidad de las extensiones varía (consulta extensiones comunitarias de GitHub Spec Kit).

Matriz de decisión de extensibilidad

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

Ejemplo: «Agregar SSO para un tenant» con ambos conjuntos de herramientas

La misma funcionalidad, distinta coreografía.

Flujo de OpenSpec

/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

Flujo de Spec Kit

/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

Perspectiva de PM: Spec Kit ofrece más puntos de revisión programados. OpenSpec ofrece un camino más corto si los requisitos de SSO ya están en openspec/specs/auth/spec.md por trabajos anteriores.

Perspectiva de ingeniería: la carpeta contracts/ de Spec Kit destaca cuando SSO afecta a muchos servicios. La integración de deltas de OpenSpec destaca cuando SSO es una evolución de una especificación de autenticación existente.

Cómo elegir (ingenieros y 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

También puedes combinar ambos: OpenSpec para especificaciones de dominio vivas y Spec Kit para exploraciones puntuales en proyectos nuevos. Esto agrega una carga de proceso: hazlo solo si está explícitamente definido quién es responsable de decidir qué directorio es la fuente de verdad.

Riesgos y límites reales

• Expectativas vs producción: ambas herramientas dan por hecho que los agentes de código son capaces. Ninguna elimina la necesidad del criterio humano ante las decisiones de producto.
• Las comparaciones de OpenSpec en su README tienen un componente de marketing. Valida las afirmaciones sobre cuál es «más ligero» o «más pesado» contra tu repositorio antes de aceptarlas.
• El flujo de Spec Kit centrado en ramas puede entrar en conflicto con los worktrees de git y los polyrepos; consulta cómo integrar Spec Kit en repositorios existentes.
• La tabla de tokens de este artículo es una inferencia. Mide tus propias ejecuciones si el costo importa.
• Solapamiento con este devlog: los artículos existentes profundizan en el uso de Spec Kit (modelos fase por fase, gestión de feedback). Este artículo aporta la comparación desde la perspectiva de OpenSpec que esos artículos no cubrían.

Fuentes

Primarias:

• Fission AI, repositorio de OpenSpec — README, licencia MIT, nota comparativa con Spec Kit (consultado el July 1, 2026)
• Fission AI, documentación del workflow OPSX de OpenSpec — acciones, esquemas, grafo de dependencias (consultado el July 1, 2026)
• Fission AI, guía de inicio de OpenSpec — estructura de directorios, formato de especificaciones delta, comportamiento al archivar (consultado el July 1, 2026)
• Fission AI, herramientas compatibles con OpenSpec — matriz de skills/comandos (consultado el July 1, 2026)
• npm, @fission-ai/openspec@1.5.0 — fecha de lanzamiento: June 28, 2026 (consultado el July 1, 2026)
• OpenSpec, openspec.dev — posicionamiento del producto, filosofía que prioriza proyectos existentes (consultado el July 1, 2026)
• GitHub, repositorio de Spec Kit — flujo principal de SDD (consultado el July 1, 2026)
• GitHub, sitio de documentación de Spec Kit — cantidades de extensiones/presets/workflows, última actualización el May 27, 2026 (consultado el July 1, 2026)
• GitHub, desarrollo guiado por especificaciones (spec-driven.md) — comandos /speckit.* y familias de artefactos (consultado el July 1, 2026)
• GitHub Blog, desarrollo guiado por especificaciones con IA — presentación del lanzamiento (consultado el July 1, 2026)

Lecturas relacionadas en este sitio:

• OpenSpec vs Superpowers: comparación de la generación de especificaciones y la implementación — comparación de capas relacionadas (artefactos de especificación vs skills de SDLC); usa el Spec workflow picker en la barra lateral del artículo
• Cómo integrar GitHub Spec Kit en repositorios existentes con Cursor
• Extensiones comunitarias de GitHub Spec Kit
• Una estrategia de modelos fase por fase para GitHub Spec Kit en 2026