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

Los desarrolladores que comparan configuraciones de Desarrollo Guiado por Especificaciones (SDD) en 2026 generalmente no se preguntan cuál es el modelo más inteligente. Se preguntan qué flujo de trabajo mantendrá alineado a un agente de IA sin ahogarlos en burocracia.

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

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

SDD está convirtiéndose en una categoría de herramientas

El Desarrollo Guiado por Especificaciones dejó de ser un ejercicio de papel a finales de 2025. Cada proveedor importante de código con IA ahora ofrece 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 “cuál herramienta gana”. Es la profundidad del proceso frente a la portabilidad. Kiro está integrado. Spec Kit es portable. Los flujos de trabajo de Claude Code son modificables. Las especificaciones malas empeoran a todos los agentes sin importar qué envoltorio elijas. Las buenas especificaciones viajan entre herramientas.

Cómo comparar configuraciones de SDD

Antes de elegir una herramienta, nombra para qué estás optimizando. La misma función puede sentirse sencilla en una configuración y burocrática en otra, dependiendo del tamaño del equipo, la antigüedad del base de código y cuánto revisión necesites.

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, a una sola nube o a un formato propietario?

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

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

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

Puntos de control de revisión – ¿Hay puertas humanas naturales entre especificar, planificar, tareas e implementar? El SDD sin revisión es solo codificación por intuición 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 las decisiones anteriores.

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

Retención (Lock-in) – ¿Qué pierdes si cambias editores, modelos o proveedores de nube en seis meses?

GitHub Spec Kit

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

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

Las desventajas son reales. Spec Kit puede producir un árbol de artefactos grande: constitución, especificación, plan, tareas, contratos, lo cual paga la pena en funciones 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 el ceremonial de cascada. Spec Kit es también más débil si quieres un IDE completamente integrado donde las especificaciones, tareas e implementación vivan en una sola superficie guiada. Añade proceso encima de tu editor existente en lugar de reemplazarlo.

Spec Kit encaja con equipos que ya tienen un asistente de codificación con IA preferido y quieren un andamiaje SDD estandarizado encima. Es especialmente fuerte para funciones de nuevo desarrollo (greenfield), empresas con múltiples agentes y cualquier persona que rechace el encadenamiento al editor.

AWS Kiro

Kiro es el IDE de desarrollo guiado por especificaciones de AWS, construido sobre un fork de VS Code / Code OSS. Donde Spec Kit trae SDD a tu stack existente, Kiro asume que SDD merece un entorno hecho a medida. Un prompt genera artefactos estructurados: tipicamente requirements.md en notación 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 ofrece Agent Hooks, automatizaciones basadas en eventos que pueden actualizar pruebas, documentos o artefactos relacionados cuando cambia la implementación. Ese ciclo bidireccional es algo que Spec Kit no proporciona por defecto: las especificaciones de Spec Kit permanecen estáticas hasta que un humano las actualiza.

Los costos son la profundidad de integración intercambiada por portabilidad. Kiro corre 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 por niveles. Los equipos empresariales ya en infraestructura de AWS a menudo encuentran eso aceptable. Los desarrolladores individuales y equipos con múltiples editores quizás 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 pregunta habitual de “¿realmente necesito otro editor?”.

Kiro encaja con desarrolladores que quieren la experiencia 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 cualquier persona migrando desde Amazon Q Developer que quiere disciplina de especificaciones sin ensamblar la cadena de herramientas manualmente. Si hoy vives en VS Code y amas tu configuración actual, Kiro pide un cambio más grande que Spec Kit.

Comandos y Skills personalizadas de Claude Code

Claude Code no ofrece un único producto SDD oficial de la manera que lo hacen Spec Kit o Kiro. Si eres nuevo en la herramienta misma, empieza 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 mismo vive en comandos personalizados, skills y plantillas markdown locales en el 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 estilo Kiro, reflejar las fases de Spec Kit con comandos slash o inventar un flujo de trabajo mínimo que encaje en un repositorio. Claude Code lee CLAUDE.md para contexto de 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 guiado por especificaciones dentro de Claude Code” están llenos de desarrolladores que copiaron la skill de otra persona, la ejecutaron una vez y volvieron a la indicación sin estructura cuando la skill se sintió lenta. El SDD de Claude Code funciona cuando tratas las skills como código: versionado, revisado y mantenido, 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 máxima flexibilidad y mantenerás el flujo de trabajo tú mismo. Para el paso de puerta de revisión específicamente, subagentes de Claude Code} pueden ejecutar una pasada de revisión independiente de contexto aislado sobre el código generado antes de que mezcles una tarea: un sustituto ligero para el rol de verificación que los Agent Hooks de Kiro proporcionan nativamente.

Superpowers: Una versión empaquetada del stack de skills DIY

Si la idea de armar ese stack de skills a mano suena exactamente al problema de disciplina sobre el que advierte la tabla anterior, Superpowers} vale la pena mirarlo. Es un paquete de skills de código abierto: lluvia de ideas, escritura de planes, desarrollo guiado por subagentes, desarrollo guiado por pruebas, solicitud de revisión de código 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 “la calidad depende enteramente de la disciplina del autor”: las skills se activan automáticamente y están diseñadas para ser flujo de trabajo obligatorio, no sugerencias opcionales que el agente puede saltarse.

El flujo de trabajo que impone se mapea de cerca al ciclo de cinco fases cubierto en Flujo de trabajo de Desarrollo Guiado por Especificaciones: de los requisitos al código: la lluvia de ideas refina una idea vaga en un documento de diseño revisado, writing-plans lo rompe en tareas pequeñas y 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-refactor antes de que algo se considere hecho. 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 una skill local en el repositorio que escribes tú mismo, Superpowers no es exclusivo de Claude Code. Ofrece manifiestos de plugin 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 armar tu propia skill de Claude Code y adoptar una herramienta más pesada y específica del IDE como Kiro: obtienes un ciclo con opinión e impuesto sin renunciar a tu editor o comprometerte con el formato de especificaciones de un solo proveedor.

Superpowers encaja con desarrolladores que les gusta el enfoque de skills de Claude Code en principio pero siguen deslizándose hacia la indicación sin estructura porque nada impone las puertas de revisión. Es un ajuste más débil si ya tienes una skill SDD específica del proyecto ajustada a tu stack: 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) toma un enfoque centrado en cambios con menos archivos generados que Spec Kit. Los benchmarks de la comunidad reportan un uso de tokens materialmente más bajo 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 en Reddit.

BMAD-METHOD (comunidad) empuja en la dirección opuesta: flujos de trabajo multiagentes y basados en roles que simulan personas de propietario de producto, arquitecto, desarrollador y revisor. BMAD puede ser poderoso en esfuerzos grandes de nuevo desarrollo donde la separación explícita de roles ayuda. También es pesado. Los equipos reportan frecuentemente que la ceremonia solo paga la pena 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 desanimando las ediciones manuales. Esa es la postura más fuerte de “especificación como fuente” entre las herramientas principales, pero Tessl permanece en beta y tiene el mayor encadenamiento de producto del grupo.

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

El patrón en todas ellas 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 el alineamiento. Empareja el peso de la herramienta al tamaño de la tarea, no al hype.

¿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 individual, base de código existente, funciones pequeñas. Empieza con skills de Claude Code o OpenSpec. Escribe un bloque corto de requisitos, 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 una skill personalizada desde cero. Renuncias a algo de ajuste específico del proyecto a cambio de un ciclo impuesto de lluvia de ideas-planificar-implementar-revisar que no depende de tu disciplina ese día.

Desarrollador individual, función de nuevo desarrollo, múltiples sesiones. Spec Kit o una skill SDD de Claude Code bien mantenida. Necesitas artefactos duraderos más que asistencia de IDE.

Equipo pequeño, editores mixtos. Spec Kit. Especificaciones en markdown plano en Git, revisadas en pull requests, 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 documentos 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. Las herramientas no reemplazan los rastros de auditoría. Solo las hacen más fáciles de producir.

Base de código existente, cambio de campo marrón (brownfield). OpenSpec o un flujo de trabajo ligero de Claude Code. La ceremonia completa de Spec Kit en cada corrección de error se sentirá como cascada. Reserva la estructura más pesada para funciones transversales.

Producto de nuevo desarrollo, 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 multiagente también deberían mirar Oh My OpenCode Agents} para patrones sobre dividir roles entre agentes: complementario a los artefactos de SDD, no un reemplazo para ellos. Si tu equipo ejecuta un agente de primera terminal en lugar de uno integrado en 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 decisiones práctica

Lo que realmente determina el éxito

La elección de herramienta importa menos que la calidad de los artefactos. Un archivo de requisitos de Kiro con criterios de aceptación vagos producirá la misma desviación que un prompt descuidado de Claude Code. Un plan de Spec Kit que liste cincuenta tareas redundantes se sentirá como 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 pequeñas lo suficiente para revisarse en una sola sesión. Escribe los no-objetivos explícitamente. Rompe las tareas en diferencias que un humano pueda leer. Valida contra criterios de aceptación antes de mezclar. Actualiza la especificación cuando la implementación descubra un mejor camino.

Si aún estás eligiendo entre SDD e indicación sin estructura para una función dada, lee Desarrollo Guiado 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 función merece una especificación en absoluto.

Las especificaciones malas empeoran a todos los agentes. 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 alineados a los agentes de IA entre sesiones, con apuestas diferentes sobre portabilidad versus integración. Spec Kit optimiza para markdown agnóstico de agentes en tu repositorio. Kiro optimiza para un IDE nativo de especificaciones guiado con agentes respaldados por AWS. Las skills de Claude Code optimizan para flujos de trabajo modificables y ligeros que solo tienen éxito cuando los mantienes.

Elige la configuración más superficial que aún elimine la ambigüedad para la función 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 de 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 lluvia de ideas a TDD a través de Claude Code, Cursor, Codex y otros agentes
• Martin Fowler sobre herramientas de SDD – análisis de Kiro, Spec Kit y Tessl