Kiro es el IDE de AWS que popularizó un flujo de spec-driven development por fases: primero requisitos, luego diseño, luego tareas y solo al final código, con una aprobación humana en cada salto.

Ese mismo flujo se puede usar desde la terminal, sin el IDE, con cc-sdd: un paquete npm que instala el conjunto de skills y comandos de Kiro dentro del agente que ya estés usando (Claude Code, OpenCode, Codex, Cursor…). Es un proyecto independiente de terceros, no un producto de AWS —el IDE es cerrado—, pero reproduce las mismas fases y los mismos documentos, y las especificaciones son compatibles y portables entre los dos.

En este tema, «Kiro» significa cc-sdd. Todo lo que sigue se ejecuta en la terminal.

• Proyecto: github.com/gotalab/cc-sdd
• Paquete: npm: cc-sdd (v3.0.2, MIT)

Requisitos: Node.js (para poder usar npx) y ejecutar el comando en la raíz del proyecto, porque instala ficheros dentro de él.

Es el destino por defecto, así que basta con:

cd mi-proyecto
npx cc-sdd@latest

Para elegir idioma y ser explícito con el agente:

npx cc-sdd@latest --claude-skills --lang es

Esto deja en el proyecto:

• .claude/skills/ — las 17 skills kiro-*
• .kiro/ — plantillas, steering y especificaciones
• CLAUDE.md — configuración del proyecto para el agente

cd mi-proyecto
npx cc-sdd@latest --opencode-skills --lang es

Esto deja en el proyecto:

• .opencode/skills/ — las mismas 17 skills
• .kiro/ — plantillas, steering y especificaciones
• AGENTS.md — configuración del proyecto para el agente

Opciones útiles:

npx cc-sdd@latest --lang es        # idioma de los documentos (en, es, ja, zh-TW, pt, de, fr...)
npx cc-sdd@latest --dry-run        # ver qué ficheros tocaría, sin escribir nada
npx cc-sdd@latest --kiro-dir docs  # usar otro directorio en lugar de .kiro

Conviene lanzar primero –dry-run sobre un proyecto que ya tenga contenido, para ver qué se va a crear o sobrescribir.

mi-proyecto/
├── .claude/skills/          # (o .opencode/skills/) las 17 skills kiro-*
├── .kiro/
│   ├── settings/templates/  # plantillas de requirements, design, tasks, steering
│   ├── settings/rules/      # reglas y criterios de generación
│   ├── steering/            # memoria del proyecto  <- la crea /kiro-steering
│   └── specs/               # una carpeta por funcionalidad <- la crea /kiro-spec-init
└── CLAUDE.md                # o AGENTS.md

Antes de ver los comandos uno a uno conviene tener el mapa, porque cc-sdd tiene dos ritmos distintos y es fácil confundirlos.

Terminado esto, el proyecto ya «sabe de sí mismo»: cualquier comando posterior arranca leyendo ese steering.

Esto es lo que se repite una vez por cada funcionalidad que quieras construir:

Los cuatro documentos viven juntos, uno por funcionalidad:

.kiro/specs/user-auth-oauth/
├── spec.json          # metadatos y estado de aprobación de cada fase
├── requirements.md    # QUÉ, en EARS
├── design.md          # CÓMO, con diagramas y plan de ficheros
├── research.md        # hallazgos de la investigación (si hubo)
└── tasks.md           # tareas, fronteras y dependencias

Entre fase y fase hay una puerta de aprobación. spec.json guarda, para cada fase, si está generated y si está approved; un comando se niega a arrancar si la fase anterior no está aprobada:

Requirements not yet approved. Approval required before design generation.

Aprobar consiste en leer el documento y lanzar el comando siguiente. La opción -y aprueba la fase anterior automáticamente y se salta esa lectura: es cómoda para prototipos y peligrosa para lo demás, porque la revisión humana entre fases es justo lo que distingue este método de pedirle a la IA que «hazme el login».

• /kiro-steering se vuelve a lanzar de vez en cuando (modo sync) para que la memoria del proyecto no se quede desfasada respecto al código que ya se ha escrito.
• Las especificaciones no se borran al terminar: quedan como documentación de por qué el código es como es, y /kiro-validate-gap las usa para saber qué hay ya implementado.

El steering es la memoria persistente del proyecto: lo que todos los demás comandos leen antes de hacer nada. Es el primer comando que hay que ejecutar, sobre todo en un proyecto que ya tiene código.

/kiro-steering

No lleva argumentos. Analiza el repositorio y genera tres documentos en .kiro/steering/:

Funciona en dos modos, y decide solo cuál aplica mirando si ya existen los tres ficheros:

• Bootstrap (primera vez): lee README, package.json, configuración, dependencias y árbol de directorios, y redacta los tres documentos a partir de las plantillas.
• Sync (mantenimiento): compara el steering existente con el código y reporta la deriva (code drift), por ejemplo «tech.md: React 18 → 19».

Reglas importantes:

• Lo que edites a mano se respeta. Las actualizaciones son aditivas: sync no pisa tus personalizaciones.
• Captura patrones, no inventarios. El objetivo es «así se nombran los servicios aquí», no una lista de los 200 ficheros del proyecto. Lo específico de una funcionalidad va en su especificación, no en el steering.
• Revisa lo que genera antes de seguir. El steering pasa a ser la fuente de verdad para el agente, así que un error aquí se propaga a todas las especificaciones.
• Conviene re-ejecutarlo periódicamente para que el contexto no se quede obsoleto.

Para conocimiento de dominio más específico existe /kiro-steering-custom, que es interactivo y crea documentos adicionales en la misma carpeta a partir de plantillas: api-standards.md, testing.md, security.md, database.md, error-handling.md, authentication.md, deployment.md…

Crea el esqueleto de la especificación de una funcionalidad.

/kiro-spec-init <descripción del proyecto>

Ejemplo:

/kiro-spec-init Autenticación de usuarios con OAuth 2.0 y tokens JWT para una aplicación Next.js

Qué hace, por pasos:

1. Genera un nombre de funcionalidad único en kebab-case a partir de la descripción (aquí, user-auth-oauth). Si la descripción es ambigua, propone 2-3 opciones y te deja elegir; si el nombre ya existe, añade un sufijo numérico (-2, -3).
2. Comprueba que la descripción contiene los tres elementos obligatorios: quién tiene el problema, cuál es la situación actual y qué debería cambiar. Si falta alguno, pregunta en lugar de rellenarlo con suposiciones propias.
3. Crea el directorio .kiro/specs/<nombre>/.
4. Escribe dos ficheros a partir de las plantillas: spec.json (metadatos: nombre, timestamp, idioma, estado de aprobación de cada fase) y requirements.md (solo el esqueleto con la descripción).

Salida típica:

## Generated Feature Name
`user-auth-oauth`

## Created Files
- ✓ .kiro/specs/user-auth-oauth/spec.json
- ✓ .kiro/specs/user-auth-oauth/requirements.md

## Next Step
/kiro-spec-requirements user-auth-oauth

Consejos:

• Cuanto más concreta sea la descripción (stack, restricciones, requisitos clave), mejor sale el nombre y mejor arrancan los requisitos.
• Revisa spec.json después de crearlo, sobre todo el campo de idioma.
• En un proyecto existente, ejecuta antes /kiro-steering.

Es el paso siguiente a /kiro-spec-init: convierte la descripción en un documento de requisitos completo y verificable.

/kiro-spec-requirements <nombre-funcionalidad>

El argumento es el nombre de la carpeta que creó /kiro-spec-init, no la descripción:

/kiro-spec-requirements user-auth-oauth

1. Carga el contexto: spec.json (idioma y metadatos), los tres ficheros de steering (product.md, tech.md, structure.md), el brief.md si existe, y la descripción que quedó en requirements.md.
2. Investiga en paralelo, delegando en subagentes para no ensuciar el contexto principal: qué hay ya implementado en el repositorio (en proyectos brownfield), investigación de dominio con búsqueda web si hace falta, y el steering adicional que sea relevante.
3. Redacta un borrador agrupando la funcionalidad en áreas lógicas, con todos los criterios de aceptación en formato EARS.
4. Pasa el borrador por una puerta de revisión (review gate): cobertura, cumplimiento de EARS, ambigüedades y límites de alcance. Corrige y vuelve a revisar, con un máximo de dos pasadas. Si aparece una ambigüedad real, se para y pregunta en lugar de inventarse el requisito.
5. Escribe requirements.md solo cuando la revisión pasa, y actualiza spec.json a phase: requirements-generated.

EARS (Easy Approach to Requirements Syntax) es una sintaxis acotada para escribir criterios de aceptación que no se puedan interpretar de dos maneras:

WHEN  <disparador>  THE <sistema> SHALL <acción>
IF    <condición>   THEN THE <sistema> SHALL <acción>
WHERE <característica> THE <sistema> SHALL <acción>
THE <sistema> SHALL <acción>

Un fragmento del requirements.md resultante:

### 1.1 Autenticación de usuarios
**FR-1.1.1**: Login con OAuth
- WHEN el usuario pulsa "Entrar con Google" THE sistema SHALL redirigir a la pantalla de consentimiento de Google
- WHEN se recibe el callback de OAuth THE sistema SHALL validar el código de autorización
- IF la validación es correcta THEN THE sistema SHALL crear una sesión con token JWT

La gracia de EARS es que cada línea es directamente un caso de prueba: hay un disparador, un sujeto y un resultado observable.

Es la regla que más cuesta respetar. El comando pregunta —y escribe— solo sobre comportamiento observable:

Prueba del algodón: si el criterio de aceptación se puede escribir sin nombrar ninguna tecnología, es un requisito. Si necesita nombrarla, es diseño.

• Es un comando iterativo: puedes lanzarlo varias veces para refinar, y respeta lo que hayas editado a mano en requirements.md.
• Revisa el documento antes de aprobarlo. El diseño y las tareas se generan a partir de aquí, así que un requisito mal puesto se arrastra hasta el código.
• Si los requisitos salen genéricos, casi siempre es que falta steering: ejecuta /kiro-steering y vuelve a lanzarlo.
• Si da «Spec not found», el nombre no coincide: mira qué carpetas hay en .kiro/specs/.
• Las reglas de formato están en .kiro/settings/rules/ears-format.md y la plantilla del documento en .kiro/settings/templates/specs/requirements.md; ambas se pueden personalizar.

Con los requisitos aprobados:

/kiro-validate-gap user-auth-oauth    # opcional, solo en proyectos con código existente
/kiro-spec-design user-auth-oauth     # diseño técnico
/kiro-spec-design user-auth-oauth -y  # ...aprobando los requisitos automáticamente

La opción -y salta la confirmación humana de la fase anterior. Cómoda, pero es justo la puerta de control que da sentido al método: úsala solo cuando ya hayas leído el documento.

Traduce el QUÉ de los requisitos al CÓMO: arquitectura, componentes, interfaces y plan de ficheros.

/kiro-spec-design <nombre-funcionalidad> [-y]

Es el comando más caro de los cuatro, porque antes de escribir nada clasifica la funcionalidad y ajusta cuánto investiga:

La investigación se reparte entre subagentes en paralelo (uno para el código existente, otro para la búsqueda web) que devuelven un resumen, no datos en bruto, para no ensuciar el contexto principal. Los hallazgos quedan escritos en research.md: qué se investigó, con qué fuentes y qué implicaciones tuvo. Es el registro que permite entender meses después por qué se eligió una librería y no otra.

• La frontera, primero de todo (boundary-first): qué posee esta especificación, qué no posee, de qué dependencias puede tirar y qué cambios obligarían a revalidar a los de al lado. Es la sección que da sentido a todo lo demás.
• Componentes e interfaces, con tipado explícito. En TypeScript, prohibido any; en lenguajes dinámicos, anotaciones de tipo y validación en los bordes.
• Diagramas Mermaid cuando la arquitectura lo pide.
• Plan de ficheros (File Structure Plan): rutas concretas, cuáles se crean y cuáles se modifican, y una responsabilidad clara por fichero. No es decoración: de aquí salen directamente las fronteras de las tareas del paso siguiente, así que un plan de ficheros vago produce una implementación vaga.
• Estrategia de pruebas derivada de los criterios de aceptación concretos, no de plantillas genéricas. Nada de «probar que el login funciona»: qué se verifica y por qué importa.
• Trazabilidad: cada componente referencia los IDs numéricos de los requisitos que cubre.

Igual que los requisitos, el borrador pasa por una puerta de revisión (cobertura de requisitos, madurez de la arquitectura, ejecutabilidad) con un máximo de dos pasadas de reparación. Si la revisión destapa un hueco real en los requisitos, se para y te manda de vuelta a la fase anterior en lugar de tapar el agujero en el diseño.

Al terminar: phase: design-generated y approvals.requirements.approved: true.

Convierte el diseño en una lista de tareas ejecutables.

/kiro-spec-tasks <nombre-funcionalidad> [-y] [--sequential]

• De 1 a 3 horas cada una. Ni un «implementar la autenticación» ni un «crear el fichero».
• Numeradas jerárquicamente: 1., 2. son cabeceras de grupo; 1.1, 1.2 son las unidades que realmente se ejecutan.
• Con entregable verificable: un fichero, un endpoint, un componente, una configuración. Cada subtarea incluye al menos una línea que describe cómo se ve que está hecha, en términos observables.
• Anotadas:
  • _Boundary: NombreComponente_ — a qué parte del sistema pertenece.
  • _Depends: 1.2_ — dependencias no evidentes entre tareas.
  • (P) — la tarea se puede ejecutar en paralelo con otras sin riesgo. Con –sequential no se marca ninguna.
• Sin prerrequisitos implícitos: si una tarea necesita que exista un runtime, un SDK o un fichero de configuración, montar eso es una tarea previa explícita. Nada de dar por hecho el andamiaje.
• Todas conectadas al sistema: no se permiten tareas huérfanas cuyo resultado no se integre en ninguna parte.

Antes de escribir tasks.md hay dos filtros:

1. Puerta de revisión del plan: ¿está cada requisito en alguna tarea? ¿está cada componente del diseño representado? ¿son todas ejecutables y verificables? ¿cuadran las dependencias y las fronteras?
2. Revisión independiente del grafo de tareas: un subagente nuevo, que lee requirements.md y design.md por su cuenta en lugar de fiarse del resumen del padre, busca prerrequisitos ocultos, errores de orden, solapamiento de fronteras y tareas demasiado grandes o vagas. Devuelve un veredicto: PASS, NEEDS_FIXES o RETURN_TO_DESIGN.

Si sale RETURN_TO_DESIGN, el comando no escribe tasks.md y te señala el hueco exacto que hay que arreglar antes. Es la última oportunidad de detectar un problema de diseño antes de que se convierta en código.

Al final muestra un resumen (cuántas tareas, cuántos requisitos cubiertos, marcas de paralelismo) y pregunta si apruebas. Solo entonces marca approvals.tasks.approved.

Ejecuta las tareas aprobadas. Es donde por fin se escribe código.

/kiro-impl <nombre-funcionalidad>                    # modo autónomo: todas las tareas pendientes
/kiro-impl <nombre-funcionalidad> 1.1,1.2            # modo manual: solo esas tareas
/kiro-impl <nombre-funcionalidad> --review off       # sin revisión por tarea (no recomendado)

• Comprueba que las tareas están aprobadas en spec.json; si no, se para.
• Descubre los comandos de validación del repositorio mirando, por este orden, package.json / pyproject.toml / go.mod / Cargo.toml, luego Makefile o justfile, luego los ficheros de CI, luego el README. De ahí saca el conjunto de comandos de test, de build y de smoke test. Prefiere los que ya usa la automatización del proyecto antes que inventarse una tubería de shell.
• Anota el estado inicial con git status –porcelain para no mezclar cambios previos con los suyos.

Una tarea por iteración, nunca varias a la vez. En cada iteración vuelve a leer tasks.md desde cero en lugar de fiarse de lo que recuerda, y al terminar se queda solo con un resumen de una línea. Ese es el truco que permite que una ejecución larga no se degrade, y que /kiro-impl sea seguro de relanzar si se interrumpe.

Cada tarea pasa por hasta tres papeles, cada uno en un subagente con contexto limpio:

Con la tarea aprobada, antes de cantar victoria aplica kiro-verify-completion: una comprobación con evidencia fresca del estado actual del código. Solo entonces marca la tarea [x] y hace commit.

• El commit lo hace el proceso padre y es selectivo: git add con las rutas exactas que ha tocado esa tarea, más tasks.md. Nunca git add -A ni git add ..
• Formato del mensaje: feat(<nombre-funcionalidad>): <descripción de la tarea>.
• Si una tarea descubre algo transversal («esta librería necesita recompilarse para Electron»), se anota en la sección ## Implementation Notes de tasks.md y se inyecta en el prompt de las tareas siguientes. Así el error no se repite quince veces.
• Si el depurador se rinde, la tarea queda marcada con _Blocked: <causa>_ y se pasa a la siguiente, o se para el proceso pidiendo revisión humana.

Terminadas las tareas, /kiro-validate-impl <nombre> valida la funcionalidad completa —integración entre tareas, cobertura de requisitos, alineación con el diseño, evidencia de la suite entera— y devuelve GO, NO-GO o MANUAL_VERIFY_REQUIRED.

Una funcionalidad de principio a fin, sobre un proyecto ya inicializado:

/kiro-discovery Álbumes de fotos con subida, etiquetado y compartición
/kiro-spec-init photo-albums
/kiro-spec-requirements photo-albums
/kiro-spec-design photo-albums
/kiro-spec-tasks photo-albums
/kiro-impl photo-albums
/kiro-validate-impl photo-albums

Si no sabes por dónde empezar, /kiro-discovery analiza la petición y te dice cuál es el siguiente comando: extender una especificación existente, implementar directamente sin spec, crear una, o descomponer en varias.

Comandos de apoyo:

Y tres skills que no se invocan a mano, pero que conviene conocer porque son las que dan las garantías: kiro-review (protocolo de revisión adversaria), kiro-debug (depuración por causa raíz) y kiro-verify-completion (exigir evidencia fresca antes de dar algo por terminado).

• Repositorio de cc-sdd
• Skill Reference — referencia del modo skills (v3)
• Command Reference — referencia de los comandos /kiro:* antiguos
• Spec-Driven Guide — la metodología completa
• Kiro IDE