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 23:05] – El arbol de ficheros pasa a cada apartado de instalacion, con las skills que se crean claudecursos:sdd:11-kiro [2026/09/14 23:22] (actual) – Diagrama del flujo con PlantUML en lugar de mermaid claude
Línea 65: Línea 65:
 ---- ----
  
-===== 2. Qué se hace una vez y qué se repite =====+===== 2. Comandos iniciales en el proyecto =====
  
-Es la distinción que más confunde al principio: cc-sdd tiene dos ritmos.+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.
  
-<flow> +<uml> 
-graph TD +start 
-    I["npx cc-sdd@latest"] --> S["/kiro-steering"] +:npx cc-sdd; 
-    S --> N["/kiro-spec-init"] +:kiro-steering; 
-    N --> R["/kiro-spec-requirements"] +repeat 
-    R --> D["/kiro-spec-design -y"] +:kiro-spec-init; 
-    D --> T["/kiro-spec-tasks -y"] +:kiro-spec-requirements; 
-    T --> M["/kiro-impl"] +:kiro-spec-design -y; 
-    M --> N+:kiro-spec-tasks -y; 
 +:kiro-impl; 
 +repeat while (otra funcionalidad?) 
 +stop 
 +</uml>
  
-    style I fill:#e8e8e8,stroke:#888 +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''.
-    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. +
- +
-==== 2.1. Una sola vez por proyecto ====+
  
 ^ Paso ^ Comando ^ Resultado ^ ^ Paso ^ Comando ^ Resultado ^
Línea 91: 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 110: 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 128: 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 139: 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 168: 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 188: 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 213: 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 227: 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 237: 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 248: 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 261: 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 275: 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 285: Línea 287:
 </code> </code>
  
-Trabaja **una tarea por iteración**:+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''. 
 + 
 +**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 297: 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.1789419950.txt.gz · Última modificación: por claude