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 las skills de Kiro dentro del agente que ya estés usando. Es un proyecto independiente de terceros, no un producto de AWS, pero reproduce las mismas fases y los mismos documentos.

En este tema, «Kiro» significa cc-sdd. Y de todos sus comandos vemos solo los seis que hacen falta para trabajar: el resto son atajos y validaciones opcionales.

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

Hace falta Node.js y ejecutar el comando en la raíz del proyecto, porque instala ficheros dentro de él.

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

Deja en el proyecto .claude/skills/ (las skills), .kiro/ (plantillas y documentos) y CLAUDE.md.

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

Deja .opencode/skills/, .kiro/ y AGENTS.md. Los comandos y las plantillas son exactamente los mismos que en Claude Code.

mi-proyecto/
├── .claude/skills/          # (o .opencode/skills/) los comandos kiro-*
├── .kiro/
│   ├── settings/            # plantillas y reglas, personalizables
│   ├── steering/            # memoria del proyecto  <- la crea /kiro-steering
│   └── specs/               # una carpeta por funcionalidad <- la crea /kiro-spec-init
└── CLAUDE.md                # o AGENTS.md

Sobre un proyecto que ya tenga contenido conviene lanzar antes npx cc-sdd@latest –dry-run para ver qué ficheros tocaría.

Es la distinción que más confunde al principio: cc-sdd tiene dos ritmos.

Los 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É
├── design.md          # CÓMO
└── tasks.md           # tareas

spec.json guarda si cada fase está generada y si está aprobada. Un comando se niega a arrancar si la fase anterior no lo está:

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: es cómoda para prototipos, pero saltarse esa lectura es renunciar a lo único que distingue este método de pedirle a la IA «hazme el login».

Crea la memoria del proyecto: lo que todos los demás comandos leen antes de hacer nada. Es lo primero que hay que ejecutar.

/kiro-steering

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

La primera vez los escribe desde cero leyendo README, dependencias y árbol de directorios. Las siguientes veces compara con el código y reporta lo que se ha desviado, respetando lo que hayas editado a mano.

Tres reglas:

• Captura patrones, no inventarios. «Así se nombran los servicios aquí», no una lista de los 200 ficheros del proyecto.
• Revísalo antes de seguir. Pasa a ser la fuente de verdad del agente: un error aquí se propaga a todas las especificaciones.
• Relánzalo de vez en cuando para que no se quede desfasado respecto al código ya escrito.

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

/kiro-spec-init <descripción de la funcionalidad>

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

Qué hace:

1. Genera un nombre único en kebab-case a partir de la descripción (aquí, user-auth-oauth). Si es ambigua, propone opciones y te deja elegir.
2. Comprueba que la descripción dice quién tiene el problema, cuál es la situación actual y qué debería cambiar. Si falta algo, pregunta en lugar de suponerlo.
3. Crea .kiro/specs/<nombre>/ con spec.json y un requirements.md vacío.

No escribe requisitos, ni diseño, ni tareas: solo la estructura. Por eso es instantáneo.

Cuanto más concreta sea la descripción —stack, restricciones, requisitos clave—, mejor arranca todo lo demás.

Convierte la descripción en un documento de requisitos verificable.

/kiro-spec-requirements user-auth-oauth

El argumento es el nombre de la carpeta, no la descripción.

EARS (Easy Approach to Requirements Syntax) es una sintaxis acotada para escribir criterios de aceptación que no admitan dos lecturas:

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 documento 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
- 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

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:

Prueba del algodón: si el criterio 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 edites a mano. Si los requisitos salen genéricos, casi siempre falta steering.

Traduce el QUÉ al CÓMO.

/kiro-spec-design user-auth-oauth

Antes de escribir nada investiga: en funcionalidades nuevas busca patrones de arquitectura y verifica versiones de dependencias; en extensiones recorre el código existente buscando los patrones que ya se usan.

design.md contiene:

• La frontera, primero de todo: qué posee esta especificación, qué no posee y de qué dependencias puede tirar.
• Componentes e interfaces con tipado explícito.
• Diagramas cuando la arquitectura lo pide.
• Plan de ficheros: rutas concretas, cuáles se crean y cuáles se modifican, una responsabilidad por fichero. De aquí salen las fronteras de las tareas del paso siguiente, así que un plan vago produce una implementación vaga.
• Estrategia de pruebas derivada de los criterios de aceptación concretos. Nada de «probar que el login funciona»: qué se verifica y por qué importa.

Si al revisar el diseño aparece un hueco real en los requisitos, se para y te manda de vuelta en lugar de taparlo aquí.

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

/kiro-spec-tasks user-auth-oauth

Cómo son las tareas:

• De 1 a 3 horas cada una. Ni «implementar la autenticación» ni «crear el fichero».
• Numeradas: 1., 2. son cabeceras de grupo; 1.1, 1.2 son lo que realmente se ejecuta.
• Con entregable verificable: un fichero, un endpoint, un componente. Cada tarea dice cómo se ve que está hecha, en términos observables.
• Anotadas con la parte del sistema a la que pertenecen (_Boundary:_), sus dependencias (_Depends:_) y si se pueden ejecutar en paralelo ((P)).
• Sin prerrequisitos implícitos: si una tarea necesita un runtime o un fichero de configuración, montar eso es una tarea previa explícita.

Antes de escribir tasks.md comprueba que cada requisito está en alguna tarea y que cada componente del diseño está representado. Al terminar muestra un resumen y pregunta si apruebas.

Es la última oportunidad de detectar un problema de diseño antes de que se convierta en código.

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

/kiro-impl user-auth-oauth              # todas las tareas pendientes
/kiro-impl user-auth-oauth 1.1,1.2      # solo esas tareas

Antes de empezar descubre los comandos de validación del repositorio —tests, build, smoke test— mirando package.json, Makefile, los ficheros de CI y el README. Prefiere los que ya usa el proyecto antes que inventarse comandos.

Después trabaja una tarea por iteración:

1. Programa con TDD: primero la prueba que falla, luego el código que la pasa.
2. Revisa el resultado de forma independiente: ejecuta git diff, lanza las pruebas y comprueba que no se ha salido de la frontera de la tarea.
3. Marca la tarea como hecha en tasks.md y hace commit solo de los ficheros de esa tarea —nunca git add -A— con el mensaje feat(<funcionalidad>): <tarea>.

Que sea una tarea por iteración es lo que hace que /kiro-impl sea seguro de relanzar si se interrumpe: al reanudar relee tasks.md y sigue por donde iba.

Una funcionalidad de principio a fin, sobre un proyecto ya inicializado con /kiro-steering:

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

Leyendo y aprobando el documento de cada fase antes de lanzar la siguiente.

• Repositorio de cc-sdd
• Spec-Driven Guide — la metodología completa
• Kiro IDE