Les exemples de cette page servent de points de départ. Une recette intégrée illustre une structure utile, et l'ensemble des recettes intégrées peut varier selon les versions du client. Modifiez les étapes, les agents, les modèles, l'effort, les limites, les transferts et les preuves d'achèvement en fonction de votre travail.
| Exemple | Structure | Preuve d'achèvement |
|---|---|---|
| Examiner et expliquer | Une étape ciblée → rapport → synthèse par l'agent principal | Artéfact de rapport avec références |
| Livrer une fonctionnalité | Exigences → conception/révision → plan → code/révision → validation | Révisions approuvées et validation finale |
| Dépanner jusqu'à vérification | Reproduire → diagnostiquer → corriger → tester ↺ | Résultat de réussite lisible par machine |
| Publier et répondre | Publier → attendre → répondre ↺ → transférer | État externe de la pull request et vérifications |
Utilisez cet exemple lorsque vous avez besoin d'une réponse autonome sans modification du code source. Commencez depuis le clavardage parent :
Utilisez un workflow pour examiner l'architecture de déploiement de ce dépôt. Ne modifiez pas le projet. Rédigez un rapport avec références qui présente les points d'entrée, les dépendances, les risques, les tests et les points de modification probables, puis résumez ici les constatations importantes.
La recette est intentionnellement petite :
brief → investigate · wf-planner → report artifact → main-agent summary
Une recette réutilisable minimale :
name: investigate-question inputs: brief: prompt report_path: file steps: - type: step id: investigate agent: wf-planner artifacts: report: "{{report_path}}" prompt: > READ-ONLY investigation; do not edit code or commit. Investigate {{brief}} and write findings to {{report_path}}. Lead with the answer, cite files and symbols, list risks and recommendations, then call send_message with severity success and the key finding.
Une seule étape garde l'exécution économique et vérifiable. La déclaration de report rend son chemin accessible aux étapes ultérieures sous la forme {{artifacts.report}} si cette recette devient un workflow plus vaste.
Mesure de protection contre les échecs : utilisez un chemin à l'intérieur de l'espace de travail de l'exécution et rendez explicite la contrainte de lecture seule. Un workflow ne limite pas, à lui seul, un agent à la lecture seule; les outils et les autorisations de l'agent sélectionné régissent toujours les effets secondaires.
Utilisez cet exemple lorsque les exigences, la conception, la planification de la mise en œuvre, la programmation, la révision indépendante et la validation finale doivent être des étapes explicites plutôt qu'une seule longue conversation. Voici la structure de la plupart des travaux sur des fonctionnalités :
La figure reproduit la topologie de la recette intégrée feature-pipeline : ses agents nommés, les deux réviseurs avec leurs remplacements de modèle, code-aggregate et validate comme étape simple de premier niveau. Le squelette qui suit est une adaptation qui ajoute une isolation explicite du worktree et une porte de validation lisible par machine; utilisez-le comme point de départ pour la politique de votre dépôt, et non comme la recette elle-même.
The entire topology stays visible. Select a node, or use the transport to trace the run from setup through validation.
Graph
Verify the isolated worktree and create a unique run directory.
Recipe selected setup
- type: step id: setup agent: wf‑coder
solid rectangles are agent steps; dashed boundaries are repeat and parallel nodes; diamonds are the conditions a repeat checks; the two reviewers run on different models on purpose
L'exemple intégré est lancé depuis Opus 5 avec un effort élevé, puis applique des remplacements là où ils sont utiles : les agents de conception et de révision s'exécutent avec un effort très élevé, les deux réviseurs de code utilisent délibérément des modèles différents (claude-fable-5 et gpt-5.6-sol) afin que leurs constatations soient réellement indépendantes, et pas seulement de nom, et l'étape setup d'une ligne s'exécute avec un effort faible. Les autres étapes héritent du modèle et de l'effort du lancement.
design-loop : au plus trois tentatives de conception/révision; arrêter seulement lorsque design-review.json indique APPROVED; abandonner si la condition n'est pas satisfaite.code-loop : au plus trois tentatives de mise en œuvre/révision; exécuter les deux révisions en parallèle, les regrouper dans code-review.json et arrêter seulement lorsque son verdict est APPROVED; abandonner si la condition n'est pas satisfaite.validate : une dernière vérification par rapport aux exigences initiales.Voici un squelette adaptable. Il conserve les mêmes étapes et ajoute deux éléments que la recette intégrée vous laisse gérer : un worktree isolé par exécution et une répétition validate-gate qui transforme la vérification finale en PASS lisible par machine ou en abandon.
name: deliver-feature inputs: task: prompt worktree_path: string run_id: string steps: - type: step id: setup agent: wf-coder prompt: > Verify that {{worktree_path}} is an absolute path to an isolated worktree. Create {{worktree_path}}/.kiro/workflow-runs/{{run_id}} for this run. Do not change the primary checkout. Report the selected path. - type: step id: requirements agent: wf-design artifacts: requirements: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/requirements.md" prompt: > In {{worktree_path}}, write testable requirements for {{task}} to {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/requirements.md. - type: repeat id: design-loop maxIterations: 3 onMaxIterations: abort stopCondition: fileCheck: path: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/design-review.json" jsonPath: verdict value: APPROVED steps: - type: step id: design-draft agent: wf-design artifacts: design: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/design.md" prompt: > In {{worktree_path}}, read {{artifacts.requirements}}. Draft or revise the design and write it to {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/design.md. - type: step id: design-review agent: wf-design-reviewer artifacts: design_review: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/design-review.json" prompt: > In {{worktree_path}}, review {{artifacts.design}} against {{artifacts.requirements}}. Write {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/design-review.json with verdict APPROVED or REVISE and the findings. - type: step id: plan agent: wf-planner artifacts: plan: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/plan.md" prompt: > In {{worktree_path}}, write an ordered implementation and validation plan from {{artifacts.requirements}} and {{artifacts.design}} to {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/plan.md. - type: repeat id: code-loop maxIterations: 3 onMaxIterations: abort stopCondition: fileCheck: path: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/code-review.json" jsonPath: verdict value: APPROVED steps: - type: step id: implement agent: wf-coder artifacts: code_summary: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/code-summary.md" prompt: > Implement {{artifacts.plan}} in {{worktree_path}} and run relevant checks. Write {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/code-summary.md with changed files, tests run, command output, and remaining risks. - type: parallel id: code-reviews joinPolicy: all branches: - type: step id: review-a agent: semantic_reviewer artifacts: review_a: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/review-a.md" prompt: > Independently review the implementation in {{worktree_path}} using {{artifacts.code_summary}}. Write findings to {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/review-a.md. Do not read other reviews. - type: step id: review-b agent: semantic_reviewer artifacts: review_b: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/review-b.md" prompt: > Independently review the implementation in {{worktree_path}} using {{artifacts.code_summary}}. Write findings to {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/review-b.md. Do not read other reviews. - type: step id: code-aggregate agent: wf-review-aggregator artifacts: code_review: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/code-review.json" prompt: > In {{worktree_path}}, read {{artifacts.review_a}} and {{artifacts.review_b}}. Write {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/code-review.json with verdict APPROVED or REVISE, deduplicated findings, and corroborated issues ranked first. - type: repeat id: validate-gate maxIterations: 1 onMaxIterations: abort stopCondition: fileCheck: path: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/validation.json" jsonPath: verdict value: PASS steps: - type: step id: validate agent: wf-coder artifacts: validation_report: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/validation.md" validation: "{{worktree_path}}/.kiro/workflow-runs/{{run_id}}/validation.json" prompt: > In {{worktree_path}}, validate the implementation against {{artifacts.requirements}} and {{artifacts.code_summary}}. Run the required checks. Write {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/validation.md and {{worktree_path}}/.kiro/workflow-runs/{{run_id}}/validation.json with verdict PASS or FAIL and the evidence. Do not fix code in this step; report honestly.
La sélection du worktree et la configuration de l'exécution sont explicites, et non des comportements automatiques du workflow. Conservez worktree_path dans une racine d'espace de travail autorisée : ouvrez ou lancez depuis le worktree isolé lui-même, ou créez le worktree dans l'espace de travail courant. Tous les chemins d'artéfacts et de fileCheck de cette recette se trouvent sous worktree_path, et un chemin fileCheck situé à l'extérieur de toutes les racines d'espace de travail autorisées fait échouer son nœud. Attribuez des valeurs run_id différentes aux exécutions simultanées afin que leurs artéfacts et leurs portes ne se chevauchent jamais. L'exemple valide la modification, mais ne contourne pas les contrôles du dépôt. Pour l'intégrer, transmettez la branche validée à Publier et répondre pour révision, puis effectuez la fusion selon le processus normal de votre dépôt une fois la pull request verte et approuvée.
Mesure de protection contre les échecs : les plafonds d'itérations limitent le temps et l'utilisation; ils ne prouvent pas la qualité. Cet exemple abandonne lorsque l'approbation de la révision ou le verdict de validation finale n'est pas obtenu, plutôt que de poursuivre silencieusement.
Utilisez cet exemple pour les échecs qui peuvent être reproduits et vérifiés mécaniquement : une compilation brisée, un test défaillant, une validation de déploiement ou une régression de performance.
Utilisez un workflow borné pour reproduire cet échec, diagnostiquer une cause à la fois, appliquer la plus petite correction et relancer la même vérification. Arrêtez seulement lorsque result.json contient verified: true; mettez l'exécution en pause après dix tentatives infructueuses.
Chaque itération reproduit l'échec, diagnostique une cause, applique la plus petite modification et relance la même vérification; la boucle se termine seulement lorsque result.json contient le verdict, et le plafond met l'exécution en pause au lieu de déclarer une réussite. Le squelette regroupe ces actions en une seule étape; divisez-les en étapes distinctes lorsque chacune nécessite son propre agent ou son propre fichier de preuve.
name: troubleshoot-until-verified inputs: issue: prompt result_path: file steps: - type: repeat id: fix-loop maxIterations: 10 onMaxIterations: pause stopCondition: fileCheck: path: "{{result_path}}" jsonPath: verified value: true steps: - type: step id: diagnose-and-fix agent: wf-coder prompt: > Reproduce {{issue}}. Inspect the latest result at {{result_path}} if it exists. Test one hypothesis, apply the smallest justified change, rerun the reproduction, and write JSON with verified, evidence, and remaining_risk fields.
Chaque itération établit de nouveau la vérité à partir du dépôt et de la même vérification. fileCheck fournit au moteur d'exécution une condition d'arrêt exécutoire; une déclaration de réussite en prose ne met pas fin à la boucle.
Mesure de protection contre les échecs : onMaxIterations: pause présente une décision plutôt que de continuer à consommer des ressources indéfiniment ou de signaler une fausse réussite.
Utilisez cet exemple lorsqu'une branche est prête pour la révision. Une veille attend sans tours de modèle, un répondant ciblé traite la nouvelle activité et la répétition se termine lorsque la pull request atteint un état final, ce qui se produit lorsque vous ou le processus de votre dépôt la fusionnez ou la fermez. Le livrable du workflow est une pull request verte et approuvée; la fusion vous revient.
La figure ci-dessous représente la boucle comme une boucle. La particule reste immobile pendant que la veille est en attente, fait un tour dans respond lorsqu'une activité survient et ne prend la sortie qu'une fois la pull request fusionnée ou fermée.
01submit opened the pull request and wait is parked on it. An empty ring is the point: while nothing happens, nothing is spent.
Between events the loop is parked: no model turns, no cost. Every event is one respond turn.
the ring is the repeat; the particle rests at the ring until an event lands, then goes once round through respond and back down through wait. Only the terminal event leaves by the spur
name: publish-and-respond inputs: branch: string run_dir: string steps: - type: step id: submit agent: wf-pr-submitter prompt: > Publish {{branch}} as a pull request, or reuse its open PR. Write its URL and metadata to {{run_dir}}/pr.json. - type: repeat id: pr-loop maxIterations: 200 onMaxIterations: pause stopWhen: wait.terminal steps: - type: watch id: wait handler: github-pr config: prRef: "{{run_dir}}/pr.json" - type: step id: respond agent: wf-pr-responder prompt: > Respond to the new PR activity in {{wait.output}}. Address feedback that is safe and in scope. Ask before changing the design, expanding scope, or altering the user experience.
Le répondant s'exécute après une activité de veille ordinaire ou finale; il peut donc effectuer le bilan final une fois la pull request fusionnée ou fermée. Le workflow ne contourne pas les identifiants, la protection des branches, les vérifications requises ou la politique d'approbation, et il n'effectue pas la fusion : il vous remet une pull request verte et approuvée, puis vous ou le processus de votre dépôt effectuez la fusion.
Mesure de protection contre les échecs : attribuez des valeurs run_dir distinctes aux exécutions simultanées afin qu'elles ne partagent pas pr.json, et utilisez des identifiants GitHub assortis du moindre privilège.
La même boucle d'attente et de réponse fonctionne pour tout ce qu'un script peut vérifier. Remplacez la veille github-pr par une veille command qui exécute votre propre programme, et la boucle attend un ticket, un déploiement ou une compilation dans un autre système; consultez Surveiller autre chose avec command.
La structure du workflow peut modifier la qualité du résultat autant que le modèle sélectionné, et la meilleure structure dépend du modèle. Un modèle qui planifie bien peut nécessiter moins de boucles de révision; un modèle rapide et moins coûteux peut nécessiter un réviseur plus rigoureux et un plafond inférieur; un modèle qui raisonne en profondeur lors d'un seul passage peut être gaspillé dans une répétition serrée. Traitez le modèle, le fournisseur, l'effort, la décomposition, la critique et la vérification comme des données d'entrée d'expérience plutôt que de supposer qu'une configuration est la meilleure, et attendez-vous à itérer.
La recette intégrée feature-pipeline constitue un exemple de réponse concret : elle investit l'effort là où le jugement importe (la conception et la révision avec un effort très élevé) et obtient de l'indépendance en utilisant des modèles différents pour ses deux réviseurs de code. Si vous changez de modèle, l'endroit approprié où investir l'effort change aussi.
Une expérience utile :
modelId et effortLevel propres à chaque étape.La disponibilité du fournisseur et du modèle dépend du compte et du client. Validez chaque modelId avant le lancement. Kiro ne sélectionne pas automatiquement les fournisseurs, ne bascule pas de l'un à l'autre et ne garantit aucun classement de performance; votre grille d'évaluation tranche.
Utilisez parallel lorsque plusieurs jugements indépendants doivent converger vers un seul résultat. Donnez à chaque branche une configuration disponible différente lorsque la diversité est utile, puis demandez à une étape d'agrégation de dédupliquer les constatations et de classer en premier les problèmes corroborés. Le mode parallèle fournit actuellement une isolation du contexte et une sémantique de jonction; ne présumez pas qu'il réduit le temps réel écoulé.
Pour une optimisation ouverte, exécutez une expérience mesurée par itération. Effectuez un commit pour une amélioration et annulez une régression. Lorsqu'il n'existe aucune condition naturelle de justesse, utilisez maxIterations comme plafond de coût explicite et mettez l'exécution en pause pour obtenir une décision humaine au plafond.
Les exemples ci-dessus sont des éléments. Le travail réel les enchaîne, et vous commencez rarement par rédiger une recette : vous décrivez le résultat dans le clavardage parent et Kiro propose le workflow, ou vous nommez une recette intégrée et lui fournissez les données d'entrée. Voici trois chaînes courantes, chacune se terminant là où le rôle de Kiro prend fin : une pull request verte et approuvée pour la livraison d'une fonctionnalité, une branche validée pour une correction locale ou un rapport avec références pour un travail en lecture seule. Toute fusion vous revient ou revient à votre dépôt.
Livrer une fonctionnalité à partir d'un ticket. Demandez à Kiro de livrer la modification dans un nouveau worktree. Il configure le worktree, rédige les exigences, boucle sur la conception et la révision, planifie, boucle sur la mise en œuvre et la révision à deux modèles, valide par rapport aux exigences, puis publie une pull request et met une veille en attente sur celle-ci. Pendant l'exécution, vous continuez à travailler dans le clavardage parent; lorsqu'un réviseur ajoute un commentaire, le répondant se réveille, traite ce qui est sûr et vous demande votre accord avant de modifier la portée. Vous effectuez la fusion lorsque vous êtes satisfait.
Corriger une compilation défaillante. Demandez à Kiro de rétablir la compilation sans modifier le comportement. Il reproduit l'échec, puis boucle sur le diagnostic, la plus petite modification et la réexécution jusqu'à ce que la même vérification réussisse, avec un plafond qui met l'exécution en pause pour vous plutôt que de s'agiter inutilement. Si la cause s'avère être une question de conception, l'étape se met en pause et pose la question; vous répondez dans la session de cette étape ou par l'intermédiaire de l'agent principal, et la boucle se poursuit avec son historique intact. Elle se termine par la correction sur une branche et le fichier de preuve qui démontre la réussite de la vérification.
Comprendre avant de modifier. Demandez à Kiro d'examiner une zone inconnue et de signaler les risques avant toute modification du code. Une étape en lecture seule produit un rapport avec références; l'agent principal le résume dans votre clavardage, et cette exécution se termine ici : vous obtenez un rapport exploitable, sans branche ni pull request, car rien n'a été modifié. Si le rapport justifie une modification, dites-le, et Kiro propose la chaîne de fonctionnalités ci-dessus en utilisant le rapport comme première donnée d'entrée, afin que l'étape des exigences parte de preuves plutôt que de votre souvenir du code source.
Gardez chaque limite explicite lorsque vous enchaînez :
Exemples de workflows