OpenSpec vs Spec Kit vs BMAD: qué framework de specs elegir

OpenSpec, GitHub Spec Kit y BMAD Method resuelven el mismo problema con tres pesos muy distintos. OpenSpec es un formato de specs ligero y neutral. Spec Kit convierte el flujo en comandos de una CLI. BMAD Method es una metodología completa por fases y con agentes especializados. Kiro, el IDE de AWS, hace algo parecido dentro de su propio editor.

Si todavía no tienes claro qué va dentro de una spec y por qué el agente la lee mejor que un prompt, empieza por qué es spec-driven development y vuelve aquí. Esto de abajo asume que ya lo sabes y que la pregunta que te queda es cuál instalar el lunes.

Framework	Qué es	Mejor para	Ceremonia que impone
OpenSpec	Una CLI de npm más una convención de carpetas: cada cambio propuesto vive en su propio directorio con la propuesta, los requisitos y las tareas	Meter specs en un repositorio que ya existe sin reorganizar nada	Baja
GitHub Spec Kit	Un toolkit que instala en tu agente un flujo de slash-commands, desde los principios del proyecto hasta la implementación	Arrancar una feature con un camino marcado paso a paso	Media. El flujo está fijado, tú decides cuánto lo sigues
BMAD Method	Una metodología por fases con agentes especializados en producto, arquitectura, UX, desarrollo y testing, más módulos por dominio	Proyectos donde clarificar y planificar pesa tanto como programar	Alta
Kiro (AWS)	Un IDE que genera `requirements.md`, `design.md` y `tasks.md` antes de tocar código	Quien ya trabaja dentro del ecosistema de AWS	Media, pero atada al editor

OpenSpec: el que menos te obliga a cambiar

OpenSpec es un formato de specs en markdown con una CLI que las organiza, y su propio repositorio declara que está construido «for brownfield not just greenfield»^[2]. Esa frase es la razón principal para elegirlo. La mayoría de nosotros no arrancamos proyectos desde cero: heredamos un repositorio con seis años encima al que hay que meterle specs sin pedir permiso para reorganizarlo.

Lo mantiene Fission-AI y se instala como cualquier paquete de npm.

# Instalar y preparar el repositorio (crea openspec/specs y openspec/changes)
npm install -g @fission-ai/openspec@latest
openspec init

# Y dentro de tu agente, los comandos del ciclo:
#   /opsx:explore   piensa en voz alta antes de comprometerte a nada
#   /opsx:propose   crea la carpeta del cambio: proposal.md, specs/, design.md, tasks.md
#   /opsx:apply     el agente implementa contra esas tareas
#   /opsx:archive   el cambio pasa a formar parte de la spec viva

El modelo mental es el de una pull request, pero para el contrato en vez de para el código. Un cambio en curso vive en openspec/changes/; cuando se completa, se archiva y sus requisitos pasan a openspec/specs/, que es la foto de cómo se comporta el sistema hoy. Esa separación entre lo que quieres cambiar y lo que ya es verdad resuelve el spec drift por diseño: no hay un documento gigante que envejece, hay propuestas que se cierran.

Es neutral respecto a la herramienta y soporta más de treinta agentes^[2]. Si mañana cambias Claude Code por Cursor, los ficheros siguen ahí y siguen sirviendo.

GitHub Spec Kit: el flujo convertido en comandos

Spec Kit convierte el ciclo de spec-driven development en slash-commands que tu agente ejecuta en orden. Es el proyecto con más tracción de los tres por bastante margen: superó las 126.000 estrellas en GitHub en agosto de 2026^[1], y viene de GitHub, lo cual no lo hace mejor pero sí hace más probable que tu equipo lo acepte sin discusión.

# Requiere uv (gestor de paquetes de Python); vX.Y.Z es la release que fijes
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init mi-proyecto --integration copilot

A partir de ahí el flujo es /speckit.constitution para fijar los no-negociables, /speckit.specify para el qué, /speckit.plan para el cómo técnico, /speckit.tasks para trocearlo e /speckit.implement para ejecutar^[1]. El detalle de ese ciclo lo desarrollo en la guía completa de spec-driven development, así que no lo repito aquí.

Lo que sí merece la pena señalar son los comandos que casi nadie menciona y que son los que de verdad usas después de la primera semana. /speckit.clarify te obliga a resolver lo que dejaste ambiguo antes de que el agente lo invente. /speckit.analyze cruza spec, plan y tareas buscando incoherencias entre ellos. /speckit.converge evalúa el código que ya existe contra la spec y añade lo que falta, que es la vía de entrada para un repositorio en marcha. Y /speckit.taskstoissues vuelca las tareas a issues de GitHub, cómodo si tu equipo ya vive ahí.

Soporta más de treinta agentes de código, entre ellos Claude Code^[1]. El precio de tanta comodidad es que el camino está trazado: si tu equipo ya tiene su propia forma de escribir requisitos, Spec Kit va a discutir contigo.

BMAD Method: fases, agentes y más llamadas al modelo

BMAD Method no es un formato de ficheros, es un proceso de trabajo completo con roles repartidos. Su bucle de entrega tiene cuatro fases nombradas: clarificar, planificar, construir y verificar, y aprender y ajustar, que devuelve a planificar^[3]. Cada tramo lo cubre una perspectiva especializada (producto, arquitectura, UX, desarrollo, testing), y encima del núcleo hay módulos para dominios concretos, desde el de arquitectura de tests hasta uno de desarrollo de videojuegos.

Se instala con npx bmad-method install, va por la versión 6 y está publicado con licencia MIT^[3]. Su repositorio es explícito en que es gratis y sin flujos de pago.

Ahora, gratis no significa barato. Ese es el matiz que se pierde en casi todas las comparativas que vas a leer: el software no cuesta nada, pero un método que pasa tu idea por varios agentes con fases separadas hace muchas más llamadas al modelo que escribir un markdown y ejecutar. Más fases y más roles significan más tokens de entrada y de salida por cada feature. No te voy a dar una cifra en euros al mes porque depende del modelo que uses, del volumen, de cuántos módulos actives y de cuánto contexto arrastre cada fase. Cualquier número que leas sin esas variables está inventado. Mide tu propio consumo durante una semana antes de comprometer al equipo.

Cuál elegir según tu caso

Antes de comparar prestaciones, calcula cuánta ceremonia va a seguir sosteniendo tu equipo dentro de dos meses. Un framework que nadie sigue vale menos que un fichero markdown que todo el mundo actualiza.

Tu situación	Lo que yo cogería
Repositorio con años encima, quieres empezar a documentar contratos sin tocar la estructura	OpenSpec
Proyecto nuevo, equipo pequeño, quieres un camino marcado y no discutir el proceso	GitHub Spec Kit
Producto con muchas partes interesadas, requisitos que hay que defender ante alguien, o entorno regulado donde el rastro de decisiones importa	BMAD Method
Tu equipo ya vive en el ecosistema de AWS y no le importa atarse al IDE	Kiro

Para un equipo de dos o tres personas, BMAD suele ser demasiado. La sobrecarga de coordinación entre agentes que resuelve es la de una organización que tú no tienes: acabas rellenando artefactos de análisis para una feature que cabía en un ticket. Al revés también pasa. Si estás construyendo algo con requisitos que alguien de fuera va a auditar, el markdown suelto de OpenSpec te va a dejar sin el rastro que necesitas.

Y hay una salida que nadie te vende porque no vende nada: los tres producen ficheros markdown versionados en git. Puedes empezar con OpenSpec, robarle a BMAD la idea de separar el análisis de la implementación, y no instalar nada de BMAD. Las specs son tuyas. El framework es prestado.

Dos errores al adoptar cualquiera de los tres

Adoptar la ceremonia antes que el hábito

Instalar el framework más completo cuando tu equipo todavía no escribe specs es la forma más rápida de que nadie escriba specs. La herramienta no crea el hábito, lo formaliza. Si en las últimas cuatro features ninguna llevaba criterios de aceptación escritos, ese es el problema a resolver, y se resuelve con un fichero markdown, no con seis agentes.

Confundir el framework con la spec

El framework genera la estructura. Lo que hace que una spec sirva sigue siendo el contenido: comportamiento externo, invariantes, contratos de integración y criterios de validación que un test pueda ejecutar. Un proposal.md generado por un agente y no revisado por nadie es exactamente igual de inútil que el prompt que reemplazó, solo que ahora ocupa sitio en el repositorio y da falsa confianza.

Dirigir agentes con criterio es la habilidad de debajo, y no la instala ninguna CLI. Si te interesa sistematizar cómo trabajas con agentes de IA más allá de las specs, en Patrones de Diseño para Agentes de IA vemos los patrones para diseñar flujos fiables.

Checklist antes de adoptar uno

Has escrito al menos dos specs a mano, sin herramienta, y han sobrevivido a una revisión.
Sabes en qué carpeta del repositorio van a vivir los ficheros y quién los revisa.
El framework soporta el agente de código que tu equipo ya usa.
Has medido el gasto de API de una feature completa con el flujo puesto.
Existe una regla escrita de cuándo NO se escribe spec.
Si mañana abandonas la herramienta, los ficheros que quedan siguen siendo legibles.

Fuentes

github/spec-kit, repositorio oficial — descripción del toolkit, instalación con specify-cli, lista de slash-commands y soporte de más de 30 agentes de código. Recuento de estrellas consultado en agosto de 2026.
Fission-AI/OpenSpec, repositorio oficial — instalación vía npm, comandos /opsx:*, organización de openspec/specs y openspec/changes, y la declaración «built for brownfield not just greenfield».
bmad-code-org/BMAD-METHOD, repositorio oficial — fases del bucle de entrega, módulos disponibles, instalación con npx bmad-method install y licencia MIT.

Preguntas Frecuentes

¿Tengo que elegir solo uno?

No, y de hecho mezclar suele salir mejor que casarse. Los tres escriben markdown en tu repositorio, así que puedes usar OpenSpec para el día a día y tomar prestada de BMAD la disciplina de separar la fase de clarificación de la de implementación sin instalar BMAD. Lo que no recomiendo es tener dos herramientas generando ficheros en paralelo sobre el mismo repositorio, porque acabas con dos versiones del contrato y ninguna manda.

¿Cuál es el más fácil para empezar hoy mismo?

OpenSpec. Un npm install -g @fission-ai/openspec@latest y un openspec init te dejan el repositorio listo en un minuto, y el primer cambio propuesto sale de un solo comando dentro de tu agente.

¿Funcionan con Claude Code?

Sí, los tres. Spec Kit declara soporte para más de treinta agentes de código, con Claude Code entre ellos, y OpenSpec da la misma cifra de herramientas compatibles. BMAD se instala en el proyecto y sus flujos los ejecuta el agente que uses. Que funcionen con tu agente no es el criterio de decisión: en 2026 lo hacen todos.

¿Spec Kit u OpenSpec?

Depende de si el proyecto es nuevo o ya existe. Verás el nombre de Spec Kit escrito a veces como «open spec» en minúsculas, pero no tiene relación con OpenSpec: son dos herramientas distintas. Spec Kit fija un camino completo desde los principios del proyecto hasta la implementación, pensado sobre todo para arrancar algo nuevo con estructura. OpenSpec no impone ese camino: es la opción cuando quieres meter specs en un repositorio que ya existe sin reorganizar nada. Si dudas, la pregunta que decide es esa: ¿arrancas de cero o documentas algo que ya corre?

¿Qué es BMAD Method?

Es una metodología de desarrollo asistido por IA organizada en cuatro fases (clarificar, planificar, construir y verificar, aprender y ajustar) con agentes especializados por rol: producto, arquitectura, UX, desarrollo y testing. A diferencia de OpenSpec (un formato de fichero) o Spec Kit (un flujo de comandos), BMAD es un proceso completo, y por eso es el que más ceremonia impone de los tres.

¿Y qué pasa con Kiro?

Kiro es el IDE de AWS que genera requirements.md, design.md y tasks.md antes de escribir código. Juega en otra categoría porque no es una capa sobre tu agente sino el editor entero, así que la decisión de adoptarlo se parece más a cambiar de herramienta de trabajo que a instalar un paquete. Lo menciono brevemente en la definición de spec-driven development, que es donde vive el detalle de cómo funciona.

¿Cuál gasta más tokens?

BMAD Method, con diferencia, porque su bucle pasa cada cambio por varias fases con agentes distintos y cada una consume contexto de entrada y produce salida. OpenSpec está en el otro extremo: la spec es un markdown y el agente la lee como leería cualquier fichero del repositorio. Es un gasto que compensa cuando el análisis vale tanto como el código, y que no compensa cuando la feature cabía en un ticket.