GitHub Spec Kit frente a Kiro frente a los flujos de trabajo SDD de Claude Code

Los desarrolladores que comparan configuraciones de Desarrollo Orientado por Especificaciones (Spec-Driven Development, SDD) en 2026 generalmente no están preguntando qué modelo es más inteligente. Están preguntando qué flujo de trabajo mantendrá a un agente de IA alineado sin sepultarlos en ceremonias.

GitHub Spec Kit, AWS Kiro y los flujos de trabajo personalizados de Claude Code implementan todos la misma idea general: requisitos, diseño, tareas, implementación y validación, pero intercambian portabilidad, profundidad de integración y la cantidad de proceso que imponen.

Si primero necesitas los conceptos, lee ¿Qué es el Desarrollo Orientado por Especificaciones? y la guía neutral de herramientas Flujo de Trabajo de Desarrollo Orientado por Especificaciones en el clúster de documentación de Arquitectura de Aplicaciones. Esta comparación se encuentra en el hub de Herramientas de Desarrollo con IA junto con reseñas de asistentes y guías de flujo de trabajo.

SDD se está convirtiendo en una categoría de herramientas

El Desarrollo Orientado por Especificaciones dejó de ser un ejercicio teórico en algún momento a finales de 2025. Cada principal proveedor de codificación con IA ahora distribuye alguna versión de especificar-planificar-implementar, y una lista creciente de herramientas independientes compite por la cantidad de estructura que añaden alrededor de ese ciclo.

La comparación que importa no es “qué herramienta gana”. Es la profundidad de proceso frente a la portabilidad. Kiro está integrado. Spec Kit es portable. Los flujos de trabajo de Claude Code son modificables. Las malas especificaciones hacen que todos los agentes sean peores, sin importar qué envoltorio elijas. Las buenas especificaciones viajan entre herramientas.

Cómo comparar configuraciones de SDD

Antes de elegir una herramienta, nombra en qué estás optimizando. La misma característica puede sentirse sin esfuerzo en una configuración y burocrática en otra, dependiendo del tamaño del equipo, la antigüedad de la base de código y cuánta revisión necesitas.

Portabilidad – ¿Pueden vivir las especificaciones como markdown plano en tu repositorio y funcionar con el agente que prefieras el próximo trimestre? O ¿están atadas a un solo IDE, una sola nube o un formato propietario?

Fricción de configuración – ¿Cuánto tiempo desde “quiero probar SDD” hasta un ciclo funcional de especificar-planificar-tareas? El andamiaje CLI, la instalación del IDE o crear tus propios comandos de barra tienen todos diferentes energías de activación.

Calidad de la especificación – ¿La herramienta te ayuda a escribir requisitos y criterios de aceptación precisos, o solo genera documentos largos? La estructura es útil. El volumen no lo es.

Ejecución de tareas – ¿Cómo rompe el trabajo en rebanadas revisables? ¿Pueden las tareas ejecutarse en paralelo? ¿Resiste las explosiones de tareas de cincuenta elementos?

Puntos de control de revisión – ¿Hay puertas humanas naturales entre especificar, planificar, tareas e implementar? SDD sin revisión es solo codificación por intuición (vibe coding) más lenta.

Anclaje al repositorio – ¿El flujo de trabajo lee convenciones del proyecto, registros de decisiones, ADRs, AGENTS.md y el código existente antes de planificar? Los agentes sin anclaje reinventan la arquitectura porque nunca ven la intención revisada detrás de decisiones anteriores.

Colaboración del equipo – ¿Pueden varias personas revisar los mismos artefactos de especificación en solicitudes de extracción (pull requests)? ¿Puedes mezclar agentes sin reescribir el proceso?

Dependencia del proveedor (Lock-in) – ¿Qué pierdes si cambias de editores, modelos o proveedores de nube en seis meses?

GitHub Spec Kit

GitHub Spec Kit es un kit de herramientas CLI de código abierto que andamia un ciclo orientado por especificaciones en tu repositorio y entrega la ejecución a cualquier agente de codificación que ya uses. El CLI specify coloca plantillas, comandos de barra y un layout de carpetas convencional. Los comandos típicos siguen una secuencia constitución-especificar-clarificar-planificar-tareas-implementar, con un paso explícito de clarificación para resolver ambigüedades antes de que comience el trabajo de arquitectura.

La ventaja definitoria de Spec Kit es la independencia del agente. La documentación oficial lo posiciona como una herramienta que funciona con Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex y docenas de otros agentes. Escribes especificaciones una vez en markdown, las commiteas como código y cambias el ejecutor sin reescribir el proceso. Eso hace que Spec Kit sea la recomendación predeterminada para equipos que quieren SDD sin apostar por un solo proveedor.

Los contrapesos son reales. Spec Kit puede producir un árbol de artefactos grande – constitución, especificación, plan, tareas, contratos – lo cual paga en características de múltiples sesiones pero se siente pesado para un pequeño ajuste de CLI. Los hilos de Hacker News comparan regularmente esa sobrecarga con la ceremonia del ciclo en cascada (waterfall). Spec Kit también es más débil si quieres un IDE totalmente integrado donde especificaciones, tareas e implementación vivan en una sola superficie guiada. Capa proceso sobre tu editor existente en lugar de reemplazarlo.

Spec Kit se ajusta a equipos que ya tienen un asistente de codificación con IA preferido y quieren un andamiaje estándar de SDD encima. Es especialmente fuerte para características nuevas (greenfield), talleres multi-agente y cualquiera que se niegue a la dependencia del editor.

AWS Kiro

Kiro es el IDE orientado por especificaciones de AWS, construido sobre un fork de VS Code / Code OSS. Donde Spec Kit trae SDD a tu pila existente, Kiro asume que SDD merece un entorno diseñado a la medida. Un prompt genera artefactos estructurados – típicamente requirements.md en notación de estilo EARS, design.md, y un tasks.md secuenciado por dependencias – antes de que los agentes escriban código de producción.

La experiencia guiada es el principal punto de venta de Kiro. Los requisitos, el diseño y las tareas son objetos de UI de primera clase junto a tu código, no archivos que gestionas a través de una CLI separada. Kiro también distribuye Agent Hooks (Ganchos de Agente), automatizaciones impulsadas por eventos que pueden actualizar pruebas, documentación o artefactos relacionados cuando la implementación cambia. Ese ciclo bidireccional es algo que Spec Kit no proporciona de serie – las especificaciones de Spec Kit permanecen estáticas hasta que un humano las actualice.

Los costos son la profundidad de integración intercambiada por la portabilidad. Kiro se ejecuta dentro de su editor, usa modelos respaldados por AWS Bedrock y factura a través de un modelo de precios basado en créditos con planes escalonados. Los equipos empresariales ya en infraestructura AWS a menudo encuentran que es aceptable. Los desarrolladores solitarios y los equipos multi-editor pueden no. Kiro también tiene bordes ásperos típicos de un IDE más nuevo – compatibilidad de extensiones, sorpresas de flujo de trabajo y la habitual pregunta “¿realmente necesito otro editor?”.

Kiro se ajusta a desarrolladores que quieren la experiencia de SDD más guiada y están cómodos adoptando un IDE nativo de especificaciones. Es una opción fuerte para equipos empresariales, entornos pesados en AWS y cualquiera que migre de Amazon Q Developer y quiera disciplina de especificaciones sin ensamblar la cadena de herramientas manualmente. Si vives en VS Code estándar hoy y amas tu configuración actual, Kiro pide un cambio más grande que el que hace Spec Kit.

Comandos y Skills personalizados de Claude Code

Claude Code no distribuye un único producto oficial de SDD de la manera en que lo hacen Spec Kit o Kiro. Si eres nuevo en la herramienta en sí, comienza con la guía de instalación y configuración de Claude Code} para la configuración, permisos y backends locales. El patrón de SDD en sí vive en comandos personalizados, skills y plantillas de markdown locales del repositorio que los desarrolladores mantienen. Anthropic fusionó los archivos antiguos .claude/commands/*.md en el mecanismo de Skills, por lo que el patrón duradero es un SKILL.md (o equivalente) que define tu lista de verificación de especificar-planificar-implementar, cargado bajo demanda.

Este enfoque es el más ligero y modificable. Puedes portar un layout de tres archivos de estilo Kiro, reflejar las fases de Spec Kit con comandos de barra, o inventar un flujo de trabajo mínimo que se ajuste a un solo repositorio. Claude Code lee CLAUDE.md para el contexto del proyecto siempre activo y extrae skills cuando la tarea coincide. Esa divulgación progresiva mantiene las sesiones enfocadas sin cargar una constitución completa en cada prompt.

La desventaja es la disciplina. Nada te obliga a pasar por puertas de aclaración o revisión a menos que construyas esas puertas tú mismo. Los hilos de Reddit y Hacker News sobre “desarrollo orientado por especificaciones dentro de Claude Code” están llenos de desarrolladores que copiaron el skill de otra persona, lo ejecutaron una vez y volvieron a la indicación no estructurada cuando el skill se sintió lento. El SDD de Claude Code funciona cuando tratas los skills como código – versionados, revisados y mantenidos – no como una descarga de prompt de una sola vez.

Para una implementación seria, lee Claude Skills y SKILL.md para Desarrolladores y codifica tus fases como skills con puntos de control de revisión explícitos. El SDD de Claude Code es la elección correcta cuando ya vives en Claude Code, quieres flexibilidad máxima y mantendrás el flujo de trabajo tú mismo. Para el paso de la puerta de revisión específicamente, los subagentes de Claude Code pueden ejecutar una pasada de revisión independiente y de contexto aislado sobre el código generado antes de que merges una tarea – un sustituto ligero para el rol de verificación que los Agent Hooks de Kiro proporcionan nativamente.

Superpowers: Una versión empaquetada de la pila de skills de bricolaje

Si arrollar esa pila de skills por tu cuenta suena exactamente a la disciplina problemática sobre la que advierte la tabla anterior, Superpowers} merece una mirada. Es un paquete de skills de código abierto – brainstorming, writing-plans, subagent-driven-development, test-driven-development, requesting-code-review y un puñado de skills de soporte – distribuido como un plugin instalable en lugar de algo que escribes desde cero. Apunta directamente a la limitación de que la “calidad depende por completo de la disciplina del autor”: los skills se disparan automáticamente y están pensados para ser un flujo de trabajo obligatorio, no sugerencias opcionales que el agente puede saltarse.

El flujo de trabajo que impone se mapea estrechamente al ciclo de cinco fases cubierto en Flujo de Trabajo de Desarrollo Orientado por Especificaciones de Requisitos a Código: brainstorming refina una idea vaga en un documento de diseño revisado, writing-plans lo rompe en pequeñas tareas verificables, subagent-driven-development despacha un subagente fresco por tarea con una revisión de dos etapas, y test-driven-development impone un estricto rojo-verde-refactorar antes de que algo sea considerado terminado. Esa última parte es más estricta de lo que la mayoría de las skills de SDD de Claude Code se molestan en ser – Superpowers elimina explícitamente el código escrito antes de que existiera una prueba fallida para él.

A diferencia de un skill local del repositorio que escribes tú mismo, Superpowers no es exclusivo de Claude Code. Distribuye manifiestos de plugins para Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid y varios otros agentes, por lo que la misma metodología te sigue entre arneses en lugar de vivir en una sola carpeta .claude/skills/. Eso lo convierte en un punto medio entre arrollar tu propio skill de Claude Code y adoptar una herramienta más pesada y específica del IDE como Kiro: obtienes un ciclo opinado e impuesto sin renunciar a tu editor ni comprometerte con el formato de especificación de un solo proveedor.

Superpowers se ajusta a desarrolladores que le gusta el enfoque de skills de Claude Code en principio pero que siguen resbalando hacia la indicación no estructurada porque nada fuerza las puertas de revisión. Es un ajuste más débil si ya tienes un skill de SDD específico del proyecto afinado a tu pila – en ese caso, estás intercambiando una pequeña cantidad de personalización por una mayor cantidad de ceremonia impuesta.

BMAD, OpenSpec y otros flujos de trabajo

No todos los equipos quieren el árbol de artefactos de Spec Kit o el IDE de Kiro. Dos alternativas aparecen constantemente en las comparaciones de 2026.

OpenSpec (Fission AI) adopta un enfoque centrado en cambios con menos archivos generados que Spec Kit. Los benchmarks de la comunidad reportan un uso de tokens materialmente menor para tareas comparables, a costa de menos estructura previa. OpenSpec tiende a ganar cuando estás modificando una base de código existente y quieres especificaciones revisables sin una fase de planificación de 800 líneas. Compete con Spec Kit en portabilidad más que con Kiro en integración de IDE. Consulta el inicio rápido de OpenSpec} para los pasos de instalación, el ciclo de explorar-proponer-aplicar-archivar y las trampas que aparecen más a menudo en Reddit.

BMAD-METHOD (comunidad) empuja en la dirección opuesta – flujos de trabajo multi-agente y basados en roles que simulan las personas de producto, arquitecto, desarrollador y revisor. BMAD puede ser poderoso en grandes esfuerzos greenfield donde la separación explícita de roles ayuda. También es pesado. Los equipos frecuentemente reportan que la ceremonia solo paga cuando el dolor de coordinación ya es agudo.

Tessl trata la especificación como la fuente literal del código generado, marcando la salida como derivada y desalentando ediciones manuales. Esa es la postura más fuerte de “especificación como fuente” entre las herramientas principales, pero Tessl sigue en beta y carga la mayor dependencia de producto del grupo.

Spec Kitty y otros andamiajes de la comunidad se sitúan entre OpenSpec y Spec Kit en peso. Valen la pena si quieres plantillas sin adoptar la cadena de herramientas completa de GitHub.

**gstack} va un paso más allá de la capa de especificación: envuelve el agente de codificación en un equipo virtual de ingeniería completo – revisión de producto, revisión de arquitectura y diseño, QA del navegador, auditorías de seguridad y la cadena de lanzamiento-despliegue – de modo que la especificación es una de varias etapas impuestas en lugar de la columna vertebral. Se ejecuta en Claude Code y nueve otros agentes, y la guía cubre cómo dejar que Spec Kit (o OpenSpec) posea la columna vertebral de planificación mientras gstack aporta las capas que una herramienta de especificaciones no impone.

El patrón a través de todos ellos es el mismo. Más proceso ayuda cuando la ambigüedad es costosa. Más proceso daña cuando la velocidad de retroalimentación importa más que la alineación. Ajusta el peso de la herramienta al tamaño de la tarea, no a la moda.

¿Qué configuración de SDD deberías usar?

No hay un ganador universal. La configuración correcta depende de quién eres, qué estás construyendo y cuánta estructura realmente mantendrás.

Desarrollador solitario, base de código existente, características pequeñas. Comienza con skills de Claude Code o OpenSpec. Escribe un bloque de requisitos corto, una lista de tareas mínima y un punto de control de revisión. No instales un árbol completo de Spec Kit para un cambio de cincuenta líneas.

Quieres el enfoque de skills de Claude Code pero sigues saltándote tus propias puertas de revisión. Instala Superpowers en lugar de escribir un skill personalizado desde cero. Renuncias a algo de ajuste específico del proyecto a cambio de un ciclo de brainstorm-planificar-implementar-revisar impuesto que no depende de tu disciplina ese día.

Desarrollador solitario, característica greenfield, múltiples sesiones. Spec Kit o un bien mantenido skill de SDD de Claude Code. Necesitas artefactos duraderos más que la guía del IDE.

Equipo pequeño, editores mixtos. Spec Kit. Especificaciones de markdown plano en Git, revisadas en solicitudes de extracción, ejecutadas por el agente que cada desarrollador prefiera.

Equipo empresarial, nativo de AWS, presión de cumplimiento. Kiro. Artefactos guiados, trazabilidad de requisitos y ganchos que mantienen documentación y pruebas más cerca de la implementación.

Entorno regulado. Kiro o Spec Kit más tu propia lista de verificación de validación – no solo skills de Claude Code a menos que codifiques puertas de cumplimiento explícitamente. La herramienta no reemplaza las auditorías. Solo las hace más fáciles de producir.

Base de código existente, cambio brownfield. OpenSpec o un flujo de trabajo ligero de Claude Code. La ceremonia completa de Spec Kit en cada corrección de errores se sentirá como ciclo en cascada. Reserva la estructura más pesada para características transversales.

Producto greenfield, muchos agentes. Spec Kit. La portabilidad importa más que el pulido del IDE cuando Copilot, Claude Code y Cursor pueden tocar todos el mismo repositorio.

Los equipos que experimentan con orquestación multi-agente también deberían mirar Oh My OpenCode Agents} para patrones sobre la división de roles entre agentes – complementario a los artefactos de SDD, no un reemplazo para ellos. Si tu equipo ejecuta un agente de primer plano de terminal en lugar de uno integrado en un IDE, la guía práctica de OpenCode CLI muestra la versión más ligera, a nivel de prompt, de la misma disciplina de planificar-antes-de-implementar – útil cuando un árbol completo de Spec Kit es más ceremonia de la que la tarea justifica.

Tabla de decisión práctica

Lo que realmente determina el éxito

La elección de la herramienta importa menos que la calidad de los artefactos. Un archivo de requisitos de Kiro con criterios de aceptación vagos producirá el mismo desvío que un prompt descuidado de Claude Code. Un plan de Spec Kit que lista cincuenta tareas redundantes se sentirá como ciclo en cascada sin importar qué agente lo implemente.

Las prácticas que viajan a través de cada configuración son aburridas y efectivas. Mantén las especificaciones lo suficientemente pequeñas para revisarse en una sola sesión. Escribe no-objetivos explícitamente. Rompe las tareas en diferencias (diffs) que un humano pueda leer. Valida contra criterios de aceptación antes de fusionar. Actualiza la especificación cuando la implementación descubre un mejor camino.

Si aún estás eligiendo entre SDD e indicación no estructurada para una característica dada, lee Desarrollo Orientado por Especificaciones vs Codificación por Intuición. La comparación de herramientas en este artículo solo importa una vez que hayas decidido que la característica merece una especificación en absoluto.

Las malas especificaciones hacen que todos los agentes sean peores. Las buenas especificaciones viajan entre herramientas.

Conclusión

GitHub Spec Kit, Kiro y los flujos de trabajo de Claude Code son tres respuestas a la misma pregunta – ¿cómo mantienes a los agentes de IA alineados entre sesiones? – con diferentes apuestas sobre portabilidad frente a integración. Spec Kit optimiza para markdown agnóstico al agente en tu repositorio. Kiro optimiza para un IDE nativo de especificaciones guiado con agentes respaldados por AWS. Los skills de Claude Code optimizan para flujos de trabajo modificables y ligeros que solo tienen éxito cuando los mantienes tú.

Elige la configuración más superficial que aún elimine la ambigüedad para la característica en cuestión. Añade estructura cuando aparezca el dolor de coordinación, no cuando una publicación de blog te lo diga. Los desarrolladores que obtienen valor del SDD en 2026 no son los que tienen la cadena de herramientas más elaborada. Son los que escriben especificaciones dignas de ser implementadas – y luego dejan que la herramienta que eligieron ejecute contra ellas.

Enlaces útiles

• Documentación de GitHub Spec Kit – referencia oficial del flujo de trabajo de Spec Kit
• Inicio rápido de Superpowers: Instalación, Flujo de trabajo y Prueba} – paquete de skills de código abierto que impone una metodología de brainstorming a TDD entre Claude Code, Cursor, Codex y otros agentes
• gstack: Un stack de ingeniería de software con IA opinado} – la opción de equipo virtual de ingeniería completo, y cómo se combina con Spec Kit, OpenSpec y Superpowers
• Martin Fowler sobre herramientas de SDD – análisis de Kiro, Spec Kit y Tessl