Introducción a Kiro Worflows

¿Qué es Kiro Workflows?

¿Cómo funciona?

Esquema

Tipos de nodo

1. step — ejecuta una sola sesión de agente con un prompt. La unidad básica de trabajo.
2. sequence — ejecuta sus nodos hijos en orden, uno tras otro.
3. parallel — ejecuta varias ramas de forma concurrente, con una política de unión (all, allSettled o any).
4. repeat — repite sus nodos hijos hasta que se cumple una condición de parada (o se alcanza maxIterations), con un comportamiento onMaxIterations de abort, continue o pause.
5. watch — sondea un sistema externo (sin LLM), por ejemplo un PR de GitHub (github-pr) o un manejador personalizado de tipo command.

Inputs (entradas)

• En el momento de la definición — la referencia de tipo puede decir cualquier cosa: "prompt", "file", "string", "whether to...", la descripción de una ruta, el nombre de una rama. Son convenciones que veremos en las recetas incluidas (p. ej. goal: "prompt", prd_path: "file", max_iterations: ...), pero son etiquetas descriptivas, no un sistema de tipos validado.
• En el momento del lanzamiento — los valores que realmente pasamos son cadenas (strings). Cuando se lanza mediante workflowPath con inputs, cada valor es una cadena (por eso run_deploy se pasa como "false", la cadena, no un booleano JSON). El runtime los interpola como texto en los prompts.
• Todo es, en última instancia, sustitución de texto. No hay validación de enum, ni exigencia de requerido/opcional, ni parseo de números por parte del runtime. Si un input debe comportarse como un booleano o una opción, esa lógica vive en el prompt del paso — p. ej. el paso de deploy lee {{run_deploy}} y el prompt indica al agente "si esto no es true, no despliegues". El agente lo interpreta; el runtime solo entrega la cadena.

• Texto libre de prompt — una descripción de tarea (goal, prompt, research_directions).
• Ruta de archivo o directorio — rutas absolutas que los pasos leen/escriben (design_path, prd_path, report_path, workdir, spec_dir, worktree_path).
• Referencia de Git — un nombre de rama o de mainline (branch, worktree_branch, mainline_branch).
• Cadena tipo bandera (flag) — un sí/no o una opción que el prompt interpreta (run_deploy).
• Escalar corto — un nombre de perfil, un conteo, un identificador (profile, max_iterations).

1. Las salidas de los pasos son algo distinto de los inputs. Además de los inputs de lanzamiento, los pasos se referencian entre sí mediante {{step_id.output}} y {{previous.output}}, y los artefactos mediante {{artifacts.<name>}}. Esos no se declaran en inputs — se producen en tiempo de ejecución. El validador sí comprueba esas referencias estructurales (que un paso referenciado se ejecute antes y produzca salida), mientras que no valida las pistas de tipo de inputs.
2. Para las formas de receta que toman inputs en el lanzamiento (un workflowPath o una receta bundled:///agent://), mantén los valores cortos — rutas, ramas, cadenas de una línea. El texto largo de la tarea va en los prompts de los pasos de la receta (incrustados cuando se crea el flujo de trabajo), no se pasa como input de lanzamiento.

Tipos de agente

• wf-coder — lee archivos, edita código, ejecuta pruebas, hace commits; implementación general.
• wf-planner — investiga una base de código y produce un plan de implementación ordenado.
• wf-design — redacta documentos de requisitos y de diseño técnico para una funcionalidad.
• wf-design-reviewer — revisa diseños técnicos buscando ambigüedad, lagunas y supuestos no verificados; veredicto mecánico.
• semantic_reviewer — revisión de código conductual y narrativa de un diff local o de un PR; escribe una reseña y un veredicto.
• wf-review-aggregator — fusiona varias salidas de revisión en un único veredicto consolidado.
• wf-auto-researcher — subagente de investigación autónomo: ejecuta experimentos, hace benchmarks, hace commit de las mejoras.
• wf-pr-submitter — abre un pull request desde una rama y registra los metadatos del PR.
• wf-pr-responder — responde a los comentarios de revisión del PR y a la retroalimentación de CI.

El primer experimento

1. Tener un flujo de testeo con varios agentes que identifiquen problemas y los reparen in situ. Una vez completado desplegar los fixes.
2. Implementar un nuevo feature, que es, permitir al usuario elegir un nivel de complejidad antes de lanzar el juego; y desplegar el nuevo feature una vez terminado. El despliegue sería condicional usando un feature flag.

Mi opinión

Documentación