Comparativa · revisada en agosto de 2026

Spec Kit
vs OpenSpec

Las dos hacen Spec-Driven Development. La diferencia no está en la calidad: está en de qué punto asumen que partes.

El veredicto, sin rodeos

Proyecto nuevo y equipo que necesita reglas comunes → Spec Kit.
Código que ya existe y quieres specs sin reescribir nada → OpenSpec.
Si dudas, baja al árbol de decisión: cuatro preguntas y sales con una elegida.

Las dos herramientas

Qué es cada una

GitHub Spec Kit

El estándar de facto. Ceremonia alta, gobierno explícito, ecosistema enorme.

Instalación: uv tool install specify-cli
Python + uv
Comandos principales: /speckit.constitution/speckit.specify/speckit.plan/speckit.tasks/speckit.implement
Qué crea en tu repo: .specify/templates/ .specify/extensions/templates/ .specify/presets/templates/ .specify/memory/
Concepto clave — Constitution: Un documento de principios que gobierna todo lo que venga después. Se escribe una vez con /speckit.constitution y condiciona cada spec, cada plan y cada tarea del proyecto.

~126.000 estrellas en GitHub · Repositorio oficial

OpenSpec

Ceremonia baja y pensado para código que ya existe. Más joven, menos ecosistema.

Instalación: npm install -g @fission-ai/openspec
Node ≥ 20.19
Comandos principales: /opsx:explore/opsx:propose/opsx:apply/opsx:archive
Qué crea en tu repo: openspec/specs/ # fuente de verdad, por dominio openspec/changes/ # un cambio en curso por carpeta openspec/changes/archive/ openspec/config.yaml
Concepto clave — Delta specs: Cada cambio declara qué requisitos añade, modifica o elimina (## ADDED / MODIFIED / REMOVED Requirements) en vez de reescribir la spec entera. Es lo que permite meter specs en un proyecto viejo sin documentarlo todo de golpe.

Proyecto joven, comunidad mucho menor · Repositorio oficial

Ocho ejes

La comparativa, eje por eje

Lo que decide de verdad, con lo que significa cada eje para tu caso.

Comparativa de GitHub Spec Kit y OpenSpec por ejes de decisión
Eje	GitHub Spec Kit	OpenSpec	Qué significa
Instalación y runtime	Python + uv · uv tool install specify-cli	Node ≥ 20.19 · npm install -g @fission-ai/openspec	Si tu equipo es 100% JavaScript, meter Python en el toolchain es fricción real de onboarding. No es un detalle menor: es la razón más común por la que un equipo abandona Spec Kit en la primera semana.
Unidad de trabajo	La feature: specify → plan → tasks → implement	El change: propose → apply → archive	Spec Kit piensa en features nuevas. OpenSpec piensa en cambios sobre algo que ya está. Esa diferencia condiciona todo lo demás.
Gobierno del proyecto	Constitution explícita como primer paso	Sin constitution; specs por dominio en openspec/specs/	La constitution brilla con varias personas tocando el mismo repo, porque codifica las decisiones que si no se repiten en cada PR. En solitario suele ser ceremonia que rellenas y no vuelves a leer.
Proyectos existentes (brownfield)	Soportado como "iterative enhancement"	Es el caso de uso central, con /opsx:onboard para documentar lo que ya hay	El diferencial más claro. OpenSpec asume que llegas con cinco años de código y ninguna spec; Spec Kit lo soporta, pero su flujo natural sigue siendo empezar de cero.
Ceremonia	Alta: 5 comandos principales + 5 opcionales de calidad	Baja: 4 comandos principales cubren el ciclo entero	Más ceremonia no es peor: es más red de seguridad. La pregunta correcta no es cuál tiene menos pasos, sino cuántos pasos vas a mantener de verdad dentro de tres meses.
Varios repos	No nativo: un .specify/ por repo	Stores (beta): la planificación vive en un repo aparte compartido por git	Si una feature aterriza en tres repos, Stores es hoy la única respuesta de las dos. Está en beta, así que trátalo como apuesta, no como base.
Formato de la spec	Plantillas en .specify/templates/, personalizables por proyecto	Markdown plano: ### Requirement (SHALL) + #### Scenario (WHEN/THEN)	El formato de OpenSpec se lee sin documentación previa, lo que importa cuando quien tiene que revisar la spec no es quien la escribió.
Ecosistema y soporte	~126.000 estrellas · 30+ agentes · respuestas para casi todo	30+ herramientas, pero comunidad joven	La tracción de Spec Kit no prueba que sea mejor herramienta; prueba que cuando te atasques a las 23:00 vas a encontrar a alguien que ya pasó por ahí. Eso vale dinero.

Lado a lado

El mismo cambio, en las dos herramientas

Añadir login con Google a una app que ya tiene login por email. Qué comandos escribes y qué acabas commiteando en cada una.

GitHub Spec Kit

/speckit.constitution
Los principios del proyecto en .specify/memory/. Se escribe una vez; si el repo ya lo tiene, te lo saltas.
/speckit.specify
La spec de la feature: qué debe pasar cuando alguien entra con Google, en historias y criterios de aceptación.
/speckit.plan
El plan técnico: qué proveedor OAuth, cómo conviven las dos formas de login, qué migración necesita la tabla de usuarios.
/speckit.tasks
La lista de tareas ejecutables derivada del plan.
/speckit.implement
El código. A partir de aquí revisas diffs, no prompts.

OpenSpec

/opsx:onboard
La foto de lo que ya hay en openspec/specs/: cómo funciona hoy el login por email. Solo la primera vez, y es el paso que Spec Kit no tiene.
/opsx:propose
La carpeta openspec/changes/add-google-login/ con proposal.md, design.md, tasks.md y las delta specs: qué requisitos añade este cambio y cuáles modifica.
/opsx:apply
El código, tachando las tareas de tasks.md conforme avanza.
/opsx:archive
El cambio se pliega sobre openspec/specs/ (que pasa a describir el login con Google incluido) y se mueve a changes/archive/. La spec vuelve a ser la verdad del sistema.

Fíjate en el primer paso de cada columna: ahí está toda la diferencia. Spec Kit empieza escribiendo lo que el proyecto debe ser; OpenSpec empieza documentando lo que ya es.

Gratis

La decisión, en un A4

Descarga gratuita

La matriz de decisión, en un A4 imprimible

Matriz para decidir en 30 segundos según cómo sea tu proyecto, más el checklist de adopción de 10 pasos con los comandos exactos de cada herramienta.

Sin spam. Solo recursos de SDD y desarrollo con IA. Te das de baja cuando quieras.

Casos reales

Cuatro situaciones concretas

SaaS nuevo, tú solo, quieres empezar bien desde el día uno

→ Spec Kit

Greenfield es su terreno y la constitution te obliga a decidir cosas que si no arrastras hasta que duelen. La ceremonia se paga sola cuando el proyecto crece.

Monolito de cinco años, sin documentación, y hay que meter una feature el viernes

→ OpenSpec

/opsx:onboard documenta el estado actual antes de añadir nada, y las delta specs te dejan especificar solo el trozo que tocas. Con Spec Kit acabarías escribiendo specs de código que no vas a tocar.

Equipo de seis, varios repos, revisiones de PR que se van en discutir criterios

→ Spec Kit, mirando Stores de reojo

La constitution corta en seco las discusiones de criterio porque ya están escritas. Si el dolor de multi-repo pesa más que eso, prueba Stores en un proyecto pequeño antes de mover el equipo.

Quieres aprender SDD como método, no casarte con una herramienta

→ OpenSpec primero

Cuatro comandos y markdown plano: la curva es corta y el método queda a la vista. Cuando entiendas para qué sirve una spec, la ceremonia de Spec Kit se lee sola.

Decide

Árbol de decisión

Cuatro preguntas, en orden. La primera que respondas que sí, esa es tu herramienta.

¿El código ya existe y no vas a reescribirlo?
Sí
OpenSpec. Empieza por /opsx:onboard para fijar la línea base antes de tocar nada.
No
Sigue a la siguiente pregunta.
¿Sois varias personas tocando el mismo repo?
Sí
Spec Kit. La constitution es exactamente el problema que resuelve.
No
Sigue a la siguiente pregunta.
¿La feature toca más de un repositorio?
Sí
OpenSpec con Stores, asumiendo que está en beta.
No
Sigue a la siguiente pregunta.
¿Tu equipo tiene Python en el toolchain sin dolor?
Sí
Spec Kit, y te llevas el ecosistema más grande.
No
OpenSpec: te ahorras el runtime extra y arrancas hoy.

Descarga gratuita

Llévate el árbol y el checklist de adopción

La matriz de decisión en un A4 imprimible más los 10 pasos para adoptar la que elijas, con los comandos exactos de cada herramienta.

Sin spam. Solo recursos de SDD y desarrollo con IA. Te das de baja cuando quieras.

Dudas

Preguntas frecuentes

¿Se pueden usar las dos a la vez?

Sí, técnicamente: viven en directorios distintos (.specify/ y openspec/) y no chocan. Pero mantener dos fuentes de verdad sobre el mismo código es una forma cara de no tener ninguna. Si las combinas, que sea por repos separados, no dentro del mismo.

¿Cuál es mejor para empezar si nunca he escrito una spec?

OpenSpec. Cuatro comandos y markdown sin sintaxis especial: el método se ve antes que la herramienta. Con Spec Kit corres el riesgo de aprenderte los comandos sin entender para qué sirve el artefacto que producen.

¿OpenSpec necesita instalación?

Sí. Se instala con npm install -g @fission-ai/openspec (Node 20.19 o superior) y luego openspec init crea el directorio openspec/ en tu proyecto. Es más ligero que Spec Kit, pero no es "sin instalación".

¿Qué son las delta specs?

La forma que tiene OpenSpec de describir un cambio: en vez de reescribir la spec completa, declaras qué requisitos añade, modifica o elimina bajo ## ADDED / MODIFIED / REMOVED Requirements. Es lo que hace viable adoptar specs en un proyecto que ya lleva años.

¿Funcionan con Claude Code, Cursor o Copilot?

Las dos soportan 30+ agentes, incluidos Claude Code, Cursor y Copilot. La sintaxis de invocación cambia según la herramienta: OpenSpec puede aparecer como /opsx:propose, /opsx-propose o @opsx-propose.

¿Las 126.000 estrellas de Spec Kit significan que es mejor?

Significan que vas a encontrar más ejemplos, más respuestas y menos sorpresas. Es un argumento de ecosistema, no de calidad del método. Para brownfield, OpenSpec sigue encajando mejor por diseño.

¿Esto sustituye a escribir specs a mano?

No, lo estructura. Las dos herramientas automatizan el formato, no el criterio. Si adoptas una antes de entender para qué sirve una spec, te ahorras el trabajo de escribirla y pierdes el de pensarla, que es el que valía.

Lo que ninguna cambia

El método importa más que la herramienta

Las dos automatizan el formato de la spec, no el criterio para escribirla. En el libro cubro las dos con ejemplos completos — OpenSpec y brownfield son el capítulo 9.

Ver el libro de SDD Todo sobre OpenSpec

Spec Kit
vs OpenSpec

Las dos hacen Spec-Driven Development. La diferencia no está en la calidad: está en de qué punto asumen que partes.

El veredicto, sin rodeos

Proyecto nuevo y equipo que necesita reglas comunes → Spec Kit.
Código que ya existe y quieres specs sin reescribir nada → OpenSpec.
Si dudas, baja al árbol de decisión: cuatro preguntas y sales con una elegida.

Comparativa de GitHub Spec Kit y OpenSpec por ejes de decisión

Eje

GitHub Spec Kit

OpenSpec

Qué significa

Instalación y runtime

Python + uv · uv tool install specify-cli

Node ≥ 20.19 · npm install -g @fission-ai/openspec

Si tu equipo es 100% JavaScript, meter Python en el toolchain es fricción real de onboarding. No es un detalle menor: es la razón más común por la que un equipo abandona Spec Kit en la primera semana.

Unidad de trabajo

La feature: specify → plan → tasks → implement

El change: propose → apply → archive

Spec Kit piensa en features nuevas. OpenSpec piensa en cambios sobre algo que ya está. Esa diferencia condiciona todo lo demás.

Gobierno del proyecto

Constitution explícita como primer paso

Sin constitution; specs por dominio en openspec/specs/

La constitution brilla con varias personas tocando el mismo repo, porque codifica las decisiones que si no se repiten en cada PR. En solitario suele ser ceremonia que rellenas y no vuelves a leer.

Proyectos existentes (brownfield)

Soportado como "iterative enhancement"

Es el caso de uso central, con /opsx:onboard para documentar lo que ya hay

El diferencial más claro. OpenSpec asume que llegas con cinco años de código y ninguna spec; Spec Kit lo soporta, pero su flujo natural sigue siendo empezar de cero.

Ceremonia

Alta: 5 comandos principales + 5 opcionales de calidad

Baja: 4 comandos principales cubren el ciclo entero

Más ceremonia no es peor: es más red de seguridad. La pregunta correcta no es cuál tiene menos pasos, sino cuántos pasos vas a mantener de verdad dentro de tres meses.

Varios repos

No nativo: un .specify/ por repo

Stores (beta): la planificación vive en un repo aparte compartido por git

Si una feature aterriza en tres repos, Stores es hoy la única respuesta de las dos. Está en beta, así que trátalo como apuesta, no como base.

Formato de la spec

Plantillas en .specify/templates/, personalizables por proyecto

Markdown plano: ### Requirement (SHALL) + #### Scenario (WHEN/THEN)

El formato de OpenSpec se lee sin documentación previa, lo que importa cuando quien tiene que revisar la spec no es quien la escribió.

Ecosistema y soporte

~126.000 estrellas · 30+ agentes · respuestas para casi todo

30+ herramientas, pero comunidad joven

La tracción de Spec Kit no prueba que sea mejor herramienta; prueba que cuando te atasques a las 23:00 vas a encontrar a alguien que ya pasó por ahí. Eso vale dinero.

Qué es cada una

GitHub Spec Kit

OpenSpec

La comparativa, eje por eje

El mismo cambio, en las dos herramientas

La decisión, en un A4

La matriz de decisión, en un A4 imprimible

Cuatro situaciones concretas

SaaS nuevo, tú solo, quieres empezar bien desde el día uno

Monolito de cinco años, sin documentación, y hay que meter una feature el viernes

Equipo de seis, varios repos, revisiones de PR que se van en discutir criterios

Quieres aprender SDD como método, no casarte con una herramienta

Árbol de decisión

¿El código ya existe y no vas a reescribirlo?

¿Sois varias personas tocando el mismo repo?

¿La feature toca más de un repositorio?

¿Tu equipo tiene Python en el toolchain sin dolor?

Llévate el árbol y el checklist de adopción

Preguntas frecuentes

El método importa más que la herramienta

Qué es cada una

GitHub Spec Kit

OpenSpec

La comparativa, eje por eje

El mismo cambio, en las dos herramientas

La decisión, en un A4

La matriz de decisión, en un A4 imprimible

Cuatro situaciones concretas

SaaS nuevo, tú solo, quieres empezar bien desde el día uno

Monolito de cinco años, sin documentación, y hay que meter una feature el viernes

Equipo de seis, varios repos, revisiones de PR que se van en discutir criterios

Quieres aprender SDD como método, no casarte con una herramienta

Árbol de decisión

¿El código ya existe y no vas a reescribirlo?

¿Sois varias personas tocando el mismo repo?

¿La feature toca más de un repositorio?

¿Tu equipo tiene Python en el toolchain sin dolor?

Llévate el árbol y el checklist de adopción

Preguntas frecuentes

El método importa más que la herramienta