Explora sin comprometerte
Lee tu código y te plantea opciones. No genera plan ni toca nada. Es el paso que se salta todo el mundo y el que evita especificar la solución equivocada.
Spec-Driven Development · revisado en agosto de 2026
Specs para el código
que ya tienes
Casi todo lo que se enseña sobre specs asume que empiezas de cero. Constitution, spec, plan, tareas, código. Precioso — e inútil cuando llegas un lunes a un repo de cuatro años que nadie va a reescribir.
OpenSpec entra por el otro lado: documenta lo que ya hay y, desde ahí, cada cambio declara solo lo que añade o modifica.
openspec/specs/tu-proyecto/spec.md
+## Purpose
+Meter specs en un repo que ya está en producción.
+## Requirements
+### Requirement: Tu proyecto ya existe
+El equipo SHALL introducir specs sin reescribir
+el código que ya funciona.
+#### Scenario: Lunes por la mañana
+- WHEN abres un repo de cuatro años
+- THEN documentas lo que hace antes de tocarlo
Lo que añade a tu flujo
Cuatro comandos, el ciclo entero
No hay un quinto. Esa es la mitad del argumento.
Propone el cambio
Crea openspec/changes/<nombre>/ con proposal.md, design.md, tasks.md y las delta specs: qué requisitos añade este cambio y cuáles modifica.
Implementa
Escribe el código siguiendo tasks.md y va tachando conforme avanza. Tú revisas diffs, no prompts.
Cierra el ciclo
Pliega el cambio sobre openspec/specs/ —que pasa a describir el sistema con la feature dentro— y lo mueve a changes/archive/. La spec vuelve a ser la verdad.
Instalación
npm install -g @fission-ai/openspec
Node ≥ 20.19. Después, openspec init en tu repo.
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
Lo que tienes que quitar
El error que rompe openspec validate
Si solo te llevas una cosa de esta página, que sea esta.
− en openspec/specs/
## ADDED Requirements ### Requirement: Login El sistema SHALL …
+ en openspec/specs/
## Purpose ## Requirements ### Requirement: Login El sistema SHALL …
## ADDED / MODIFIED / REMOVED Requirements es sintaxis de delta: pertenece a un change en vuelo, dentro de openspec/changes/. Una spec de línea base en openspec/specs/ abre con ## Purpose y ## Requirements.
Lo incómodo es cómo falla: el parser no revienta. Te reporta requirements 0 y sigue. Tienes specs escritas, bien redactadas, y la herramienta se comporta como si el archivo estuviera vacío.
Gratis
Llévate la decisión resuelta
Descarga gratuita
La matriz de decisión, en un A4 imprimible
Para elegir entre OpenSpec y Spec Kit 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 una.
Sin spam. Solo recursos de SDD y desarrollo con IA.
¿OpenSpec o Spec Kit?
Comparativa por ocho ejes, el mismo cambio recorrido en las dos herramientas y un árbol de decisión de cuatro preguntas.
Ver la comparativa →Generador de specs para brownfield
Pega un módulo, un README o un package.json y te devuelve la spec de línea base en formato OpenSpec, lista para openspec/specs/.
Abrir la herramienta →Lo que ninguna herramienta cambia
El criterio no se automatiza
OpenSpec y Spec Kit automatizan el formato de la spec. El criterio para escribirla sigue siendo tuyo.
Spec-Driven Development
El capítulo 9 va entero de OpenSpec y proyectos existentes: cómo introducir specs de forma gradual sin reescribir ni documentarlo todo. El resto es el método que hay debajo, agnóstico de herramienta.
Ver el libro →Construye con IA
El módulo 7 recorre el ecosistema spec-first con Spec Kit y OpenSpec. En el módulo 9 se construye una app real cuyas nueve capabilities viven en openspec/specs/ y pasan openspec validate --all 9/9. Specs de verdad, no de diapositiva.