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:59] – Quitar opciones poco frecuentes: seleccion de tareas en impl, --dry-run, marcador de paralelismo 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>
  
-----+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 ===== +----
- +
-Es la distinción que más confunde al principio: cc-sdd tiene dos ritmos.+
  
-<flow> +===== 2. Comandos iniciales en el proyecto =====
-graph TD +
-    I["npx cc-sdd@latest"] --> S["/kiro-steering"] +
-    S --> N["/kiro-spec-init"] +
-    N --> R["/kiro-spec-requirements"] +
-    R --> D["/kiro-spec-design -y"] +
-    D --> T["/kiro-spec-tasks -y"] +
-    T --> M["/kiro-impl"] +
-    M --> N+
  
-    style I fill:#e8e8e8,stroke:#888 +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.
-    style S fill:#e8e8e8,stroke:#888 +
-</flow>+
  
-En gris, lo que se hace una sola vez. El resto se repite por cada funcionalidad nueva, y de ahí la flecha de vuelta.+<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 73: 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 92: 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 110: Línea 145:
  
 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. 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 121: 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 150: 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''). +**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 170: 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 195: 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 209: 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>
Línea 219: Línea 247:
 </code> </code>
  
-El ''-y'' aprueba los requisitos de la fase anterior; sin él, el comando se para.+Traduce el QUÉ al CÓMO. El ''-y'' aprueba los requisitos de la fase anterior; sin él, el comando se para.
  
-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. +**Produce** ''design.md'' con:
- +
-''design.md'' contiene:+
  
   * **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 230: 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>
Línea 243: Línea 267:
 </code> </code>
  
-El ''-y'' aprueba el diseño de la fase anterior.+Convierte el diseño en una lista de tareas ejecutables. El ''-y'' aprueba el diseño de la fase anterior.
  
-Cómo son las tareas:+**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».
Línea 257: 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>
Línea 267: Línea 287:
 </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 281: 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 -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. +
- +
----- +
- +
-===== 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.1789419550.txt.gz · Última modificación: por claude