Análisis Profundo de Frameworks SDD: GitHub Spec Kit, OpenSpec y BMAD-METHOD Comparados

Lectura previa recomendada: Desarrollo Guiado por Especificaciones con IA Agéntica · Paradigmas Alternativos en Ingeniería de Software con IA · Orquestar Agentes de IA en Pipelines CI/CD

El ecosistema SDD ha producido tres frameworks que abordan el mismo problema fundamental —mantener a los agentes de IA alineados con tu intención arquitectónica— desde tres ángulos completamente diferentes. GitHub Spec Kit trata tu proyecto como un documento constitucional. OpenSpec trata cada cambio como una propuesta que necesita aprobación antes de que se toque una sola línea de código. BMAD-METHOD trata toda tu organización de desarrollo como un escuadrón multi-agente a orquestar.

Este artículo no es una tabla comparativa rápida. Es un análisis orientado a la investigación de lo que cada framework realmente hace bajo el capó, dónde destaca, dónde falla, y cómo un desarrollador independiente o un equipo pequeño podría pensar en elegir entre ellos.

---

El Problema Compartido: Colapso de Contexto en IA Agéntica

Antes de diseccionar cada framework, conviene nombrar el problema exacto que todos resuelven.

Cuando instruyes a un agente de codificación de IA para implementar una funcionalidad, este genera código que es correcto en un sentido sintáctico estrecho pero a menudo incorrecto en un sentido arquitectónico más amplio. Usa la capa de abstracción equivocada. Ignora una restricción de rendimiento que documentaste hace seis meses. Reintroduce un patrón que explícitamente prohibiste.

La causa raíz es el colapso de contexto: el agente no tiene acceso duradero y estructurado a tus decisiones arquitectónicas acumuladas. El historial de chat es efímero. Los comentarios de código están dispersos. Un README es un documento de marketing, no un contrato legible por máquinas.

Los tres frameworks intentan resolver esto exteriorizando tu intención arquitectónica en artefactos persistentes y versionados que los agentes pueden consultar antes de generar cualquier cosa. Difieren radicalmente en cómo estructuran esos artefactos y cuándo los hacen cumplir.

---

1. GitHub Spec Kit — El Enfoque Constitucional

Filosofía Central

Spec Kit fue desarrollado internamente por GitHub mientras construía las funcionalidades de Copilot y se publicó como código abierto bajo MIT a finales de 2025. Su metáfora central es jurídica: tu proyecto tiene una constitución, y cada especificación de funcionalidad es legislación que debe cumplirla.

El framework no es principalmente una herramienta de flujo de trabajo. Es un sistema de gestión de contexto para agentes de IA. El archivo de constitución (.specify/memory/constitution.md) es el artefacto que se espera que el agente lea antes de tomar cualquier acción.

Anatomía de un Proyecto Spec Kit

.specify/
├── memory/
│   └── constitution.md        # La "estrella polar" — siempre cargada como contexto
├── specs/
│   └── feature-auth.md        # Especificación a nivel de funcionalidad
├── plans/
│   └── plan-auth.md           # Plan de implementación vinculado a la spec
└── tasks/
    └── tasks-auth.md          # Lista de tareas atómicas generada automáticamente

La constitución codifica:

• Estándares de ingeniería (mínimos de cobertura de tests, requisitos de revisión de código)
• Restricciones de arquitectura (patrones elegidos, anti-patrones prohibidos)
• Mandatos tecnológicos (librerías aprobadas, dependencias prohibidas)
• Reglas de seguridad y cumplimiento normativo
• Requisitos operacionales (observabilidad, protocolos de despliegue)

El flujo de cuatro fases (/speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks) está deliberadamente bloqueado en cada fase: un agente de IA no puede avanzar a la implementación sin la aprobación humana del plan. Esta es la decisión de diseño más importante del framework. Mantiene a los humanos como árbitros finales de la intención arquitectónica mientras delega la ejecución mecánica a los agentes.

Fortalezas

Para desarrolladores independientes y equipos pequeños, el modelo de constitución de Spec Kit es genuinamente poderoso. Una vez que inviertes el tiempo en escribir una constitución exhaustiva —lo que típicamente lleva unas horas para un proyecto bien comprendido— el agente de IA gana una “memoria” persistente de tus preferencias que sobrevive entre sesiones. Ya no te repites. El agente ya sabe que prefieres composición funcional sobre jerarquías de clases, o que tienes una política estricta de no-any en TypeScript, o que cada operación de base de datos debe estar envuelta en un mecanismo de reintentos.

Las compuertas de fase también imponen disciplina de una manera que es sorprendentemente difícil de replicar manualmente. Cuando el agente no puede avanzar más allá de “plan” sin tu aprobación, te ves obligado a leer y criticar el plan antes de que diez horas de implementación vayan en una dirección que no pretendías.

Debilidades

El modelo de constitución asume claridad greenfield — que ya conoces tu arquitectura lo suficientemente bien como para escribirla. Para proyectos brownfield, o proyectos en exploración activa, la constitución se queda obsoleta rápidamente o se cubre de tantas advertencias que pierde su autoridad.

La compuerta de cuatro fases también es un cuello de botella. Para cambios pequeños y claramente delimitados (una corrección de bug, un refactor menor), la ceremonia completa specify → plan → tasks es una sobrecarga significativa. Spec Kit no tiene un “modo ligero” para cambios triviales.

Mejor Para

Proyectos con arquitecturas estables y bien comprendidas. Equipos (o devs en solitario) que ya se han comprometido con un stack tecnológico específico y un conjunto de patrones. Flujos de trabajo nativos de GitHub con Copilot. Cualquier situación donde el costo de que un agente de IA se desvíe de tu arquitectura es alto.

---

2. OpenSpec — El Enfoque de Propuesta de Cambio

Filosofía Central

OpenSpec, mantenido por Fission-AI, parte de un punto de partida diferente: asume que modificas un sistema existente con más frecuencia de lo que construyes desde cero. Su metáfora central no es el derecho constitucional sino la gestión del cambio: cada modificación al código base comienza como una propuesta formal.

La spec no es un documento persistente a nivel de proyecto sino un artefacto por cambio que vive y muere con el cambio que describe.

Anatomía de un Cambio OpenSpec

openspec/
├── main/
│   └── specs/                 # Specs canónicas y en vigor del proyecto
│       ├── features.md
│       └── scenarios.md
└── changes/
    └── ch-0042-add-oauth/     # Directorio de cambio aislado
        ├── proposal.md        # Por qué / Qué / Alcance
        ├── specs/             # Deltas: adiciones, modificaciones, eliminaciones
        │   └── oauth-spec.md
        ├── tasks.md           # Lista de verificación atómica y verificable
        └── design.md          # Decisiones arquitectónicas opcionales

El directorio specs/ dentro de un cambio contiene deltas de spec — documentos que marcan explícitamente cada requisito como una adición, modificación o eliminación respecto a la spec principal. Esta es la innovación clave del framework: modela el cambio en lugar del estado.

El Paso de Validación

OpenSpec incluye una CLI (openspec validate) que verifica la alineación spec-tarea antes de que comience la implementación. El validador confirma que cada tarea traza de vuelta a un requisito de spec y que ninguna tarea es un huérfano sin intención documentada. Esto detecta discrepancias entre lo que se propuso y lo que se planeó antes de escribir código.

npx openspec init
npx openspec new-change "add-oauth-login"
# Rellenar proposal.md, specs/ y tasks.md
npx openspec validate   # Asegura coherencia spec ↔ tarea
# Implementar
npx openspec archive    # Fusiona deltas en las specs principales

Diseño Brownfield-First

La cualidad más distintiva de OpenSpec es que fue diseñado para la realidad desordenada de las bases de código existentes. El comando archive es el mecanismo: cuando un cambio es probado y fusionado, los deltas de spec se pliegan de vuelta al directorio principal main/specs/. Con el tiempo, incluso una base de código que empezó sin specs acumula una spec completa y precisa por contribución incremental. Esto es construcción retroactiva de specs — no necesitas escribir la spec completa antes de empezar; cada cambio contribuye su pieza.

Esto hace que OpenSpec sea especialmente adecuado para el escenario común del desarrollador indie: un proyecto que llevas construyendo dos años sin documentación formal, donde quieres empezar a introducir desarrollo asistido por IA sin tener que reescribir toda tu documentación primero.

Fortalezas

• La amigabilidad brownfield es la característica definitoria. Puedes empezar con un main/specs/ vacío y construirlo incrementalmente.
• Aislamiento de cambios: como cada cambio es un directorio autocontenido, los agentes de IA tienen exactamente el contexto que necesitan y nada más. Esto reduce el ruido y la alucinación por carga de contexto demasiado amplio.
• Trazabilidad por diseño: la cadena propuesta → delta de spec → tarea → código crea un rastro de auditoría natural. Siempre puedes responder “¿por qué existe este código?” consultando el cambio archivado.
• Agnóstico a herramientas: todos los artefactos son Markdown plano. Funciona con cualquier agente de IA que pueda leer archivos.

Debilidades

• La ceremonia por cambio es más ligera que la de Spec Kit pero sigue requiriendo disciplina. Para prototipado rápido o trabajo verdaderamente exploratorio, incluso un corto proposal.md puede sentirse como fricción.
• No existe el equivalente de la constitución de Spec Kit — ningún documento persistente a nivel de proyecto que el agente consulte antes de actuar. Las specs principales de OpenSpec crecen incrementalmente pero no están diseñadas para ser “cargadas como contexto” de la misma manera preventiva que una constitución.
• La herramienta CLI es más nueva y menos madura que la integración de Spec Kit con Copilot.

Mejor Para

Proyectos en evolución, modernización de sistemas legados, escenarios brownfield. Desarrolladores independientes que quieren introducir rigor de manera incremental sin escribir una spec completa de antemano. Proyectos donde los cambios son pequeños y frecuentes, y donde la trazabilidad a nivel de cambio importa más que la constitución a nivel de proyecto.

---

3. BMAD-METHOD — El Enfoque de Orquestación Multi-Agente

Filosofía Central

BMAD (Breakthrough Method for Agile AI-Driven Development, o Método Revolucionario para el Desarrollo Ágil Impulsado por IA) es el más ambicioso de los tres frameworks. Mientras que Spec Kit y OpenSpec son principalmente herramientas de especificación, BMAD es un sistema de orquestación de agentes que utiliza especificaciones como protocolo de comunicación inter-agente.

La metáfora central es organizacional: tu proyecto de desarrollo es gestionado por un equipo de agentes de IA especializados, cada uno con un rol definido en el ciclo de vida ágil. El desarrollador humano no es el implementador; es el product owner y aprobador final.

El Escuadrón de Agentes

BMAD incluye un escuadrón preconfigurado de más de 20 agentes definidos como archivos Markdown y YAML versionados:

Agente	Rol	Artefacto Principal
Analyst (Analista)	Recopilación de requisitos	PRD (Doc. de Requisitos del Producto)
Architect (Arquitecto)	Diseño del sistema, ADRs	Doc. de Arquitectura
PM	Planificación de sprints, hitos	Project brief
Scrum Master	Creación de historias, gestión de sprints	Historias de usuario
Developer (Desarrollador)	Generación de código	Implementación
QA	Estrategia de pruebas	Plan de pruebas
UX Expert (Experto UX)	Flujos de usuario, specs de UI	Docs de diseño
Librarian (Bibliotecario)	Documentación, gestión del conocimiento	Índice de documentos

Cada agente se define como un archivo YAML que especifica su persona, experiencia, comandos disponibles, estrategia de gestión de memoria y protocolos de traspaso entre agentes. Este es el principio Agent-as-Code: un agente no es una configuración en un panel de control sino un artefacto versionado que vive en tu repositorio.

El Ciclo de Vida

Visión del Producto
     ↓
[Agente Analista] → PRD.md
     ↓
[Agente Arquitecto] → architecture.md, ADRs
     ↓
[Agente PM] → project-brief.md, hitos
     ↓
[Scrum Master] → user-stories/sprint-N/
     ↓
[Agente Desarrollador] → src/ (implementación de funcionalidad)
     ↓
[Agente QA] → tests/, quality-report.md
     ↓
[Agente de Release] → despliegue

En cada traspaso, el agente receptor recibe los artefactos producidos por el agente anterior como contexto. El doc de arquitectura informa al agente desarrollador. El PRD informa los criterios de aceptación del agente QA. El contexto se preserva entre agentes, no solo dentro de una sesión de agente individual.

Fortalezas

• Orquestación end-to-end: BMAD es el único framework que modela el ciclo de vida completo del desarrollo, desde la recopilación de requisitos hasta el despliegue. Los otros se centran en la fase especificación-a-implementación.
• Conocimiento organizacional persistente: porque los agentes, sus personas y su conocimiento se definen como archivos en el repositorio, el contexto acumulado del “equipo” sobrevive a los reinicios de sesión y a la rotación del equipo.
• Adaptable a la escala del proyecto: BMAD incluye configuraciones “IDE mode” más ligeras para devs en solitario y configuraciones empresariales completas para equipos grandes. La misma metodología escala.
• Excelente para proyectos complejos: cuando una funcionalidad requiere coordinación entre decisiones de arquitectura, diseño de UI e implementación de backend, la separación de roles de BMAD previene el colapso de contexto cognitivo que ocurre cuando un agente intenta ser todo.

Debilidades

• Alta ceremonia para cambios pequeños: el ciclo de vida completo de BMAD es una sobrecarga significativa para una corrección de bug o una funcionalidad pequeña. El framework es más valioso en las etapas de arquitectura y planificación, no en la etapa de mantenimiento.
• Curva de aprendizaje pronunciada: con más de 20 agentes, cada uno con su propia configuración YAML y conjunto de comandos, la configuración inicial no es trivial. La documentación es exhaustiva pero densa.
• Requiere compromiso: cambiar a BMAD a mitad de un proyecto requiere migrar la documentación existente a la estructura de artefactos de BMAD. Es factible pero requiere un esfuerzo deliberado.
• Menos centrado en specs: como el valor de BMAD está en la coordinación de agentes, los artefactos de spec individuales (PRD, doc de arquitectura) tienen una estructura menos rigurosa que las specs con compuertas de fase de Spec Kit o los deltas formales de OpenSpec.

Mejor Para

Proyectos grandes y complejos donde el ciclo de vida completo del desarrollo se beneficia de la especialización de agentes. Desarrolladores independientes que quieren simular un equipo de desarrollo completo usando agentes de IA. Proyectos que empiezan desde cero (greenfield), donde los agentes de planificación de BMAD pueden establecer la arquitectura antes de que se escriba una sola línea de código.

---

Análisis Comparativo

Por Fase del Proyecto

Fase	Mejor Framework	Razonamiento
Nuevo proyecto, definición de arquitectura	BMAD	Los agentes Analista + Arquitecto producen planificación inicial exhaustiva
Desarrollo de funcionalidad greenfield	Spec Kit	Las compuertas de fase imponen disciplina y calidad de spec
Cambio brownfield a sistema existente	OpenSpec	El modelo de propuesta de cambio diseñado para modificación, no creación
Modernización de sistema legado	OpenSpec	Construcción incremental de specs via mecanismo de archivo
Coordinación de equipo grande	BMAD	Los roles de agente reflejan la estructura del equipo ágil
Dev independiente, specs de alta calidad	Spec Kit	El modelo de constitución proporciona contexto persistente entre sesiones

Por Modelo de Especificación

Framework	Alcance de Spec	Vida Útil de Spec	Aplicación
Spec Kit	Proyecto (constitución) + Funcionalidad	Permanente	Compuertas de fase, integración con Copilot
OpenSpec	Delta por cambio	Ciclo de vida del cambio, luego archivado	CLI openspec validate
BMAD	Artefacto por rol (PRD, doc arq., etc.)	Sprint / hito	Protocolos de traspaso entre agentes

Por Integración con Herramientas de IA

• Spec Kit: Integración profunda con GitHub Copilot mediante comandos slash. Los comandos /speckit.* son funciones de primera clase de Copilot. Menos fricción para equipos nativos de GitHub.
• OpenSpec: Flujo de trabajo agnóstico a herramientas basado en Markdown. Funciona con cualquier agente de IA (Claude Code, Cursor, Copilot, Codex). Requiere gestión manual de archivos.
• BMAD: Diseñado para orquestación entre múltiples plataformas de IA. El instalador de BMAD genera AGENTS.md y archivos YAML de agente que funcionan con Claude Code, Cursor y herramientas similares. El “IDE mode” está optimizado para Cursor.

Combinando los Frameworks

Estos frameworks no son mutuamente excluyentes. Un flujo de trabajo SDD maduro podría usar:

1. BMAD para la concepción del proyecto y planificación arquitectónica (aprovechando los agentes Analista y Arquitecto para producir PRD y ADRs)
2. Spec Kit para el desarrollo de funcionalidades (convirtiendo el doc de arquitectura de BMAD en una constitución, luego usando las compuertas de fase de Spec Kit para funcionalidades individuales)
3. OpenSpec para mantenimiento y cambios brownfield (una vez el proyecto está establecido, usando propuestas de cambio para todas las modificaciones)

Este enfoque por capas no es hipotético — varios equipos han documentado el uso de BMAD para planificación mientras adoptan OpenSpec o Spec Kit para la disciplina en la fase de implementación.

---

Recomendación Práctica para Desarrolladores Independientes

Si eres un desarrollador independiente manteniendo uno o más proyectos personales:

Empieza con OpenSpec. El diseño brownfield-first significa que puedes introducir disciplina de spec en proyectos existentes sin tener que reescribir toda la documentación. El modelo de propuesta de cambio encaja con el ritmo natural del desarrollo indie: tienes una idea, la delimitas, la implementas. OpenSpec solo añade una pequeña capa de formalización a la fase de delimitación.

Añade el concepto de constitución de Spec Kit una vez que hayas acumulado suficiente historial de cambios para articular tu arquitectura. Escribe una constitución a partir de tus cambios acumulados en OpenSpec — será más precisa y específica que cualquier cosa escrita especulativamente de antemano.

Explora BMAD cuando abordes un proyecto nuevo significativo desde cero o cuando una funcionalidad sea lo suficientemente compleja como para beneficiarse genuinamente de separar el diseño arquitectónico de la implementación.

El hilo común: el valor del SDD es proporcional a la durabilidad de los artefactos que produce. Las specs efímeras escritas para satisfacer un proceso y luego descartadas añaden ceremonia sin beneficio. Las specs que los agentes realmente leen, que sobreviven a los reinicios de sesión y que evolucionan junto con el código — esos son los artefactos que vale la pena escribir.

---

Referencias y Lecturas Adicionales

• Repositorio de GitHub Spec Kit
• Comando Constitution de Spec Kit — DeepWiki
• Introducción al Desarrollo Guiado por Especificaciones con Spec Kit — Blog de Desarrolladores de Microsoft
• Extendiendo Spec Kit para Revisiones de PR Basadas en Constitución — Mark Hazleton
• Repositorio de OpenSpec — Fission-AI
• Documentación Oficial de OpenSpec
• Análisis Profundo de OpenSpec: Arquitectura y Práctica — Redreamality
• Repositorio de BMAD-METHOD
• Documentación Oficial de BMAD-METHOD
• Guía de BMAD-METHOD: Desarrollo Ágil Impulsado por IA — Redreamality
• Orquestación de Agentes en BMAD — DeepWiki
• Orquestación Multi-Agente: BMAD, Claude Flow y Gas Town — re:cinq
• Agent-as-Code: BMAD-METHOD — DEV Community