logongas

Herramientas de usuario

Herramientas del sitio

Ocultar Menú
Traza:
cursos:sdd:11-kiro

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
Próxima revisión		Revisión previa
cursos:sdd:11-kiro [2026/09/14 22:32] – Recorte al camino minimo: fuera discovery, spec-batch, validate-*, spec-status y los internos de impl/design/tasks claudecursos:sdd:11-kiro [2026/09/14 23:22] (actual) – Diagrama del flujo con PlantUML en lugar de mermaid claude
Línea 5: Línea 5:
 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. 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.+**En este tema, «Kiro» significa cc-sdd.** 
  
   * Proyecto: [[https://github.com/gotalab/cc-sdd|github.com/gotalab/cc-sdd]] (v3.0.2, MIT)   * Proyecto: [[https://github.com/gotalab/cc-sdd|github.com/gotalab/cc-sdd]] (v3.0.2, MIT)
Línea 22: Línea 22:
 </code> </code>
  
-Deja en el proyecto ''.claude/skills/'' (las //skills//), ''.kiro/'' (plantillas y documentos) y ''CLAUDE.md''.+<code> 
 +mi-proyecto/ 
 +├── .claude/skills/              # las skills de Kiro 
 +│   ├── kiro-steering/ 
 +│   ├── kiro-spec-init/ 
 +│   ├── kiro-spec-requirements/ 
 +│   ├── kiro-spec-design/ 
 +│   ├── kiro-spec-tasks/ 
 +│   └── kiro-impl/ 
 +├── .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 
 +</code>
  
 ==== 1.2. En OpenCode ==== ==== 1.2. En OpenCode ====
Línea 30: Línea 44:
 npx cc-sdd@latest --opencode-skills --lang es npx cc-sdd@latest --opencode-skills --lang es
 </code> </code>
- 
-Deja ''.opencode/skills/'', ''.kiro/'' y ''AGENTS.md''. Los comandos y las plantillas son exactamente los mismos que en Claude Code. 
- 
-==== 1.3. Estructura que se crea ==== 
  
 <code> <code>
 mi-proyecto/ mi-proyecto/
-├── .claude/skills/          # (o .opencode/skills/) los comandos kiro-*+├── .opencode/skills/            # las skills de Kiro 
 +│   ├── kiro-steering/ 
 +│   ├── kiro-spec-init/ 
 +│   ├── kiro-spec-requirements/ 
 +│   ├── kiro-spec-design/ 
 +│   ├── kiro-spec-tasks/ 
 +│   └── kiro-impl/
 ├── .kiro/ ├── .kiro/
-│   ├── settings/            # plantillas y reglas, personalizables +│   ├── settings/                # plantillas y reglas, personalizables 
-│   ├── steering/            # memoria del proyecto  <- la crea /kiro-steering +│   ├── steering/                # memoria del proyecto  <- la crea /kiro-steering 
-│   └── specs/               # una carpeta por funcionalidad <- la crea /kiro-spec-init +│   └── specs/                   # una carpeta por funcionalidad <- la crea /kiro-spec-init 
-└── CLAUDE.md                # o AGENTS.md+└── AGENTS.md
 </code> </code>
  
-Sobre un proyecto que ya tenga contenido conviene lanzar antes ''npx cc-sdd@latest --dry-run'' para ver qué ficheros tocaría.+Cambia la carpeta de las //skills// y el fichero de configuración del agente; el contenido de ''.kiro/'' y los comandos son idénticos a los de Claude Code.
  
 ---- ----
  
-===== 2. Qué se hace una vez y qué se repite =====+===== 2. Comandos iniciales en el proyecto ===== 
 + 
 +Estos son los pasos que se dan **una sola vez**, al empezar con el proyecto. A partir de ahí, lo único que se repite es el ciclo de la sección siguiente.
  
-Es la distinción que más confunde al principio: cc-sdd tiene dos ritmos.+<uml> 
 +start 
 +:npx cc-sdd; 
 +:kiro-steering; 
 +repeat 
 +:kiro-spec-init; 
 +:kiro-spec-requirements; 
 +:kiro-spec-design -y; 
 +:kiro-spec-tasks -y; 
 +:kiro-impl; 
 +repeat while (otra funcionalidad?) 
 +stop 
 +</uml>
  
-==== 2.1. Una sola vez por proyecto ====+Los dos primeros pasos se dan una sola vez. El resto se repite por cada funcionalidad nueva, y de ahí la flecha de vuelta de ''kiro-impl'' a ''kiro-spec-init''.
  
 ^ Paso ^ Comando ^ Resultado ^ ^ Paso ^ Comando ^ Resultado ^
Línea 59: Línea 89:
 | Crear la memoria del proyecto | ''/kiro-steering'' | ''.kiro/steering/'' con tres documentos | | Crear la memoria del proyecto | ''/kiro-steering'' | ''.kiro/steering/'' con tres documentos |
  
-==== 2.2. Una vez por cada funcionalidad ====+==== 2.1. La memoria del proyecto ==== 
 + 
 +''/kiro-steering'' crea lo que en cc-sdd se llama //steering//: la **memoria del proyecto**, lo que todos los demás comandos leen antes de hacer nada. Son tres documentos en ''.kiro/steering/'': 
 + 
 +^ Fichero ^ Qué recoge ^ 
 +| ''product.md'' | Para qué sirve el producto, qué valor aporta, capacidades principales | 
 +| ''tech.md'' | Stack tecnológico, frameworks, decisiones técnicas y restricciones | 
 +| ''structure.md'' | Organización de directorios, patrones de arquitectura, convenciones de nombres | 
 + 
 +Sin //steering//, cada especificación arranca a ciegas y el agente reinventa las convenciones del proyecto en cada funcionalidad. Con él, todas parten del mismo contexto. 
 + 
 +Es lo primero que hay que ejecutar, y conviene **revisar los tres documentos antes de seguir**: pasan a ser la fuente de verdad del agente, así que un error aquí se propaga a todas las especificaciones. 
 + 
 +---- 
 + 
 +===== 3. Creación de una nueva especificación ===== 
 + 
 +Esto es lo que se repite **una vez por cada funcionalidad** que quieras construir. 
 + 
 +==== 3.1. Las cinco fases ====
  
 ^ Fase ^ Comando ^ Documento que produce ^ ^ Fase ^ Comando ^ Documento que produce ^
 | Inicializar | ''/kiro-spec-init <descripción>'' | ''spec.json'' | | Inicializar | ''/kiro-spec-init <descripción>'' | ''spec.json'' |
 | Requisitos (el QUÉ) | ''/kiro-spec-requirements <nombre>'' | ''requirements.md'' | | Requisitos (el QUÉ) | ''/kiro-spec-requirements <nombre>'' | ''requirements.md'' |
-| Diseño (el CÓMO) | ''/kiro-spec-design <nombre>'' | ''design.md'' | +| Diseño (el CÓMO) | ''/kiro-spec-design <nombre> -y'' | ''design.md'' | 
-| Tareas | ''/kiro-spec-tasks <nombre>'' | ''tasks.md'' |+| Tareas | ''/kiro-spec-tasks <nombre> -y'' | ''tasks.md'' |
 | Implementación | ''/kiro-impl <nombre>'' | **código** y //commits// | | Implementación | ''/kiro-impl <nombre>'' | **código** y //commits// |
  
Línea 78: Línea 127:
 </code> </code>
  
-==== 2.3. Entre fase y fase está el humano ====+==== 3.2. Entre fase y fase está el humano ====
  
 ''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á: ''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á:
Línea 86: Línea 135:
 </code> </code>
  
-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».+<note important>**Hay que pasar ''-y'' en dos de los cinco comandos.** ''/kiro-spec-requirements'' y ''/kiro-spec-design'' generan su documento pero **no** preguntan si lo apruebas, así que la aprobación la registra el comando siguiente con ''-y''. ''/kiro-spec-tasks'' sí pregunta al terminar, y por eso ''/kiro-impl'' no necesita nada.</note> 
 + 
 +^ Comando ^ ¿Necesita ''-y''? ^ Qué aprueba ese ''-y'' ^ 
 +| ''/kiro-spec-init'' | No | — | 
 +| ''/kiro-spec-requirements'' | No | — | 
 +| ''/kiro-spec-design'' | **Sí** | los **requisitos** de la fase anterior | 
 +| ''/kiro-spec-tasks'' | **Sí** | el **diseño** de la fase anterior | 
 +| ''/kiro-impl'' | No | las tareas ya quedaron aprobadas al final de ''/kiro-spec-tasks'' | 
 + 
 +Sin ''-y'' el comando se para con el mensaje de arriba. **''-y'' no es un atajo para ir más deprisa: es la forma de decir «ya he leído el documento anterior y me vale».** Léelo de verdad antes de escribirlo. 
 + 
 +==== 3.3. Una funcionalidad de principio a fin ==== 
 + 
 +<code> 
 +/kiro-spec-init Álbumes de fotos con subida, etiquetado y compartición 
 +/kiro-spec-requirements photo-albums 
 +/kiro-spec-design photo-albums -y 
 +/kiro-spec-tasks photo-albums -y 
 +/kiro-impl photo-albums 
 +</code> 
 + 
 +Leyendo y aprobando el documento de cada fase antes de lanzar la siguiente.
  
 ---- ----
  
-===== 3. /kiro-steering =====+===== 4. Referencia de comandos =====
  
-Crea la **memoria del proyecto**: lo que todos los demás comandos leen antes de hacer nada. Es lo primero que hay que ejecutar.+==== 4.1. /kiro-steering ====
  
 <code> <code>
Línea 98: Línea 168:
 </code> </code>
  
-No lleva argumentos. Analiza el repositorio y genera tres documentos en ''.kiro/steering/'':+Crea o actualiza la memoria del proyecto. No lleva argumentos.
  
-^ Fichero ^ Qué recoge ^ +**Produce** tres documentos en ''.kiro/steering/'': ''product.md'' (para qué sirve el producto), ''tech.md'' (stack y decisiones técnicas) y ''structure.md'' (organización y convenciones).
-| ''product.md'' | Para qué sirve el producto, qué valor aporta, capacidades principales | +
-| ''tech.md'' | Stack tecnológico, frameworks, decisiones técnicas y restricciones | +
-| ''structure.md'' | Organización de directorios, patrones de arquitectura, convenciones de nombres |+
  
 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. 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.   * **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.   * **Relánzalo de vez en cuando** para que no se quede desfasado respecto al código ya escrito.
  
----- +==== 4.2. /kiro-spec-init ====
- +
-===== 4. /kiro-spec-init ===== +
- +
-Crea el esqueleto de la especificación de **una** funcionalidad.+
  
 <code> <code>
Línea 127: Línea 187:
 </code> </code>
  
-Qué hace:+Crea el esqueleto de la especificación de **una** funcionalidad.
  
-  - 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. +**Produce** ''.kiro/specs/<nombre>/'' con ''spec.json'' y un ''requirements.md'' vacío. El nombre lo genera él en ''kebab-case'' a partir de la descripción: aquí, ''user-auth-oauth''.
-  - 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. +
-  - 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.+  * 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. 
 +  * 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.
  
-Cuanto más concreta sea la descripción —stack, restricciones, requisitos clave—, mejor arranca todo lo demás. +==== 4.3. /kiro-spec-requirements ====
- +
----- +
- +
-===== 5. /kiro-spec-requirements ===== +
- +
-Convierte la descripción en un documento de requisitos **verificable**.+
  
 <code> <code>
Línea 147: Línea 201:
 </code> </code>
  
-El argumento es el nombre de la carpeta, no la descripción.+Convierte la descripción en un documento de requisitos **verificable**. El argumento es el nombre de la carpeta, no la descripción. 
 + 
 +**Produce** ''requirements.md'' con los criterios de aceptación en formato EARS.
  
-==== 5.1. Formato EARS ====+=== Formato EARS ===
  
-EARS (//Easy Approach to Requirements Syntax//) es una sintaxis acotada para escribir criterios de aceptación que no admitan dos lecturas:+EARS (//Easy Approach to Requirements Syntax//) es una sintaxis acotada para escribir criterios que no admitan dos lecturas:
  
 <code> <code>
 WHEN  <disparador>   THE <sistema> SHALL <acción> WHEN  <disparador>   THE <sistema> SHALL <acción>
 IF    <condición>    THEN 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> THE <sistema> SHALL <acción>
 </code> </code>
Línea 172: Línea 227:
 Cada línea es directamente un caso de prueba: hay un disparador, un sujeto y un resultado observable. Cada línea es directamente un caso de prueba: hay un disparador, un sujeto y un resultado observable.
  
-==== 5.2. Requisitos son el QUÉ, no el CÓMO ====+=== Requisitos son el QUÉ, no el CÓMO ===
  
 Es la regla que más cuesta respetar: Es la regla que más cuesta respetar:
Línea 186: Línea 241:
 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//. 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//.
  
----- +==== 4.4. /kiro-spec-design ====
- +
-===== 6. /kiro-spec-design ===== +
- +
-Traduce el QUÉ al CÓMO.+
  
 <code> <code>
-/kiro-spec-design user-auth-oauth+/kiro-spec-design user-auth-oauth -y
 </code> </code>
  
-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.+Traduce el QUÉ al CÓMO. El ''-y'' aprueba los requisitos de la fase anterior; sin él, el comando se para.
  
-''design.md'' contiene:+**Produce** ''design.md'' con:
  
   * **La frontera, primero de todo**: qué posee esta especificación, qué **no** posee y de qué dependencias puede tirar.   * **La frontera, primero de todo**: qué posee esta especificación, qué **no** posee y de qué dependencias puede tirar.
Línea 205: Línea 256:
   * **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.   * **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.   * **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.
 +
 +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.
  
 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í. 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í.
  
----- +==== 4.5. /kiro-spec-tasks ====
- +
-===== 7. /kiro-spec-tasks ===== +
- +
-Convierte el diseño en una lista de tareas ejecutables.+
  
 <code> <code>
-/kiro-spec-tasks user-auth-oauth+/kiro-spec-tasks user-auth-oauth -y
 </code> </code>
  
-Cómo son las tareas:+Convierte el diseño en una lista de tareas ejecutables. El ''-y'' aprueba el diseño de la fase anterior. 
 + 
 +**Produce** ''tasks.md''. Cómo son las tareas:
  
   * **De 1 a 3 horas cada una.** Ni «implementar la autenticación» ni «crear el fichero».   * **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.   * **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.   * **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)'').+  * **Anotadas** con la parte del sistema a la que pertenecen y con sus dependencias.
   * **Sin prerrequisitos implícitos**: si una tarea necesita un //runtime// o un fichero de configuración, montar eso es una tarea previa explícita.   * **Sin prerrequisitos implícitos**: si una tarea necesita un //runtime// o un fichero de configuración, montar eso es una tarea previa explícita.
  
Línea 230: Línea 281:
 Es la última oportunidad de detectar un problema de diseño antes de que se convierta en código. Es la última oportunidad de detectar un problema de diseño antes de que se convierta en código.
  
----- +==== 4.6. /kiro-impl ====
- +
-===== 8. /kiro-impl ===== +
- +
-Ejecuta las tareas aprobadas. Es donde por fin se escribe código.+
  
 <code> <code>
-/kiro-impl user-auth-oauth              # todas las tareas pendientes +/kiro-impl user-auth-oauth
-/kiro-impl user-auth-oauth 1.1,1.2      # solo esas tareas+
 </code> </code>
  
-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.+Ejecuta las tareas aprobadas. Es donde por fin se escribe código. No necesita ''-y'': las tareas se aprobaron al final de ''/kiro-spec-tasks''.
  
-Después trabaja **una tarea por iteración**:+**Produce** código y //commits//, trabajando **una tarea por iteración**:
  
   - Programa con TDD: primero la prueba que falla, luego el código que la pasa.   - Programa con TDD: primero la prueba que falla, luego el código que la pasa.
Línea 255: Línea 301:
 ---- ----
  
-===== 9. Resumen ===== +===== 5. Enlaces =====
- +
-Una funcionalidad de principio a fin, sobre un proyecto ya inicializado con ''/kiro-steering'': +
- +
-<code> +
-/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 +
-</code> +
- +
-Leyendo y aprobando el documento de cada fase antes de lanzar la siguiente. +
- +
-<note>**Guiones frente a dos puntos.** En las versiones 1.x y 2.x los comandos se llamaban ''/kiro:steering'' y ''/kiro:spec-init'', con dos puntos. Desde la 3.0 son ''/kiro-steering'' y ''/kiro-spec-init'', con guion. Los antiguos siguen funcionando pero están obsoletos.</note> +
- +
----- +
- +
-===== 10. Enlaces =====+
  
   * [[https://github.com/gotalab/cc-sdd|Repositorio de cc-sdd]]   * [[https://github.com/gotalab/cc-sdd|Repositorio de cc-sdd]]
cursos/sdd/11-kiro.1789417954.txt.gz · Última modificación: por claude