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 están preguntando qué modelo es el más inteligente. Están preguntando qué flujo de trabajo mantendrá alineado a un agente de IA sin soterrarlos 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 hacen concesiones en términos de portabilidad, profundidad de integración y la cantidad de proceso que imponen.

Si primero necesitas los conceptos, lee ¿Qué es el Desarrollo Guiado por Especificaciones? y la guía neutral en cuanto a 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 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 Guiado por Especificaciones dejó de ser un ejercicio de papel 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 profundidad de proceso versus portabilidad. Kiro está integrado. Spec Kit es portable. Los flujos de trabajo de Claude Code son modificables. Especificaciones deficientes hacen que cada agente sea peor sin importar qué envoltorio elijas. Buenas especificaciones viajan entre herramientas.

Cómo comparar configuraciones de SDD

Antes de elegir una herramienta, nombra para 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 edad de la base de código y la cantidad de revisión que 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 pasa 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 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 descompone la herramienta el trabajo en porciones revisables? ¿Pueden ejecutarse las tareas en paralelo? ¿Resiste las explosiones de listas 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 más lenta.

Anclaje al repositorio – ¿El flujo de trabajo lee convenciones del proyecto, registros de decisiones, ADR, 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 en 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?

Bloqueo (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 crea un andamiaje para un ciclo guiado por especificaciones en tu repositorio y delega la ejecución al agente de codificación que ya uses. El CLI specify descarga plantillas, comandos de barra y una estructura de carpetas convencional. Los comandos típicos siguen una secuencia de constitución-especificar-clarificar-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 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 de Spec Kit la recomendación predeterminada para equipos que quieren SDD sin apostar por un solo proveedor.

Las concesiones son reales. Spec Kit puede producir un árbol de artefactos grande: constitución, especificación, plan, tareas, contratos, lo cual compensa 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 de cascada. Spec Kit también es más débil si quieres un IDE totalmente integrado donde las especificaciones, tareas e implementación vivan en una superficie guiada única. Capa un proceso sobre 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 características de terreno virgen (greenfield), tiendas multi-agente y cualquiera que se niegue al bloqueo del editor.

AWS Kiro

Kiro es el IDE guiado 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 medida. Un prompt genera artefactos estructurados, típicamente 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 adminstras a través de un CLI separado. Kiro también distribuye Agent Hooks, automatizaciones basadas en 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 por niveles. Los equipos empresariales ya en infraestructura de AWS a menudo encuentran eso aceptable. Los desarrolladores solitarios y los equipos multi-editor 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 habitual pregunta “¿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 con mucha carga de AWS y cualquiera que migre desde Amazon Q Developer y quiera disciplina de especificaciones sin ensamblar la cadena de herramientas manualmente. Si hoy vives en VS Code estándar y amas tu configuración actual, Kiro pide un cambio mayor que 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 SDD en sí vive en comandos personalizados, skills y plantillas de markdown locales al repositorio que los desarrolladores mantienen. Anthropic integró los archivos .claude/commands/*.md más antiguos 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 el más modificable. Puedes portar una estructura de tres archivos estilo Kiro, reflejar las fases de Spec Kit con comandos de barra o inventar un flujo de trabajo mínimo que encaje en un solo repositorio. Claude Code lee CLAUDE.md para el contexto del proyecto siempre activo y extrae skills cuando la tarea coincide. Esa revelació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 un skill de otra persona, lo ejecutaron una vez y volvieron a la indicación sin estructura cuando el skill se sintió lento. SDD en Claude Code funciona cuando tratas los 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. SDD en Claude Code es la elección correcta cuando ya vives en Claude Code, quieres máxima flexibilidad y mantendrás el flujo de trabajo tú mismo. Para el paso de puerta de revisión específicamente, los subagentes de Claude Code pueden ejecutar un pase de revisión independiente, con contexto aislado, sobre el código generado antes de que fusiones 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 DIY

Si crear esa pila de skills a mano suena exactamente al problema de disciplina que la tabla anterior advierte, Superpowers} merece una mirada. Es un paquete de skills de código abierto: lluvia de ideas, escritura de planes, desarrollo impulsado por subagentes, desarrollo impulsado por pruebas, solicitud de revisión de código y un puñado de skills de apoyo, distribuido como un plugin instalable en lugar de algo que escribes desde cero. Ataca directamente la limitación de que “la calidad depende enteramente de la disciplina del autor”: los skills se activan automáticamente y están destinados a ser un flujo de trabajo obligatorio, no sugerencias opcionales que el agente pueda saltarse.

El flujo de trabajo que impone se mapea estrechamente al ciclo de cinco fases cubierto en Flujo de Trabajo de Desarrollo Guiado por Especificaciones desde los requisitos hasta el código}): la lluvia de ideas refina una idea vaga en un documento de diseño revisado, la escritura de planes lo descompone en tareas pequeñas verificables, el desarrollo impulsado por subagentes despacha un subagente fresco por tarea con una revisión de dos etapas, y el desarrollo impulsado por pruebas impone un estricto rojo-verde-refactor antes de que algo se considere terminado. Esa última parte es más estricta de lo que la mayoría de los skills 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 al 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 crear tu propio skill de Claude Code y adoptar una herramienta más pesada y específica de IDE como Kiro: obtienes un ciclo opinado e impuesto sin renunciar a tu editor ni 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 fuerza las puertas de revisión. Es un ajuste más débil si ya tienes un skill SDD específico del proyecto ajustado 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) toma un enfoque centrado en el cambio con menos archivos generados que Spec Kit. Las pruebas de la comunidad informan de un uso de tokens materialmente menor para tareas comparables, a costa de menos estructura inicial. 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. Compite con Spec Kit en portabilidad más que con Kiro en integración de IDE.

BMAD-METHOD (comunidad) empuja en la dirección opuesta: flujos de trabajo multi-agente y basados en roles que simulan personas de propietario de producto, arquitecto, desarrollador y revisor. BMAD puede ser poderoso en grandes esfuerzos de terreno virgen donde la separación explícita de roles ayuda. También es pesado. Los equipos frecuentemente informan que la ceremonia solo compensa 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 lleva el mayor bloqueo de producto del grupo.

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

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 perjudica cuando la velocidad de retroalimentación importa más que el alineamiento. Ajusta 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 mantendrás realmente.

Desarrollador solitario, base de código existente, características pequeñas. Comienza 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 un skill personalizado 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 solitario, característica de terreno virgen, múltiples sesiones. Spec Kit o un skill SDD de Claude Code bien mantenido. Necesitas artefactos duraderos más que asistencia de IDE.

Equipo pequeño, editores mixtos. Spec Kit. Especificaciones 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 hooks que mantienen la documentación y las 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 registros de auditoría. Solo las hacen más fáciles de producir.

Base de código existente, cambio en 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 características transversales.

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

Los equipos que experimentan con orquestación multi-agente también deberían mirar Oh My OpenCode Agents} para patrones sobre cómo dividir roles entre agentes, complementario a los artefactos SDD, no un reemplazo para ellos.

Tabla de decisión práctica

Lo que realmente determina el éxito

La elección de herramienta importa menos que la calidad del artefacto. 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 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 lo suficientemente pequeñas para revisarlas en una sola sesión. Escribe los no-objetivos explícitamente. Divide las tareas en diferencias que un humano pueda leer. Valida contra los criterios de aceptación antes de fusionar. 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 característica 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 característica merece una especificación en absoluto.

Las especificaciones deficientes hacen que cada agente sea peor. 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 en portabilidad versus 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.

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 diga que lo hagas. 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 que valen la pena implementar, 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
• Superpowers Quickstart: 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 entre Claude Code, Cursor, Codex y otros agentes
• Martin Fowler sobre herramientas de SDD – análisis de Kiro, Spec Kit y Tessl