Commencez dans le clavardage parent. Décrivez le résultat, les contraintes, les agents et la profondeur de révision dont vous avez besoin; Kiro peut générer un workflow pour la tâche à accomplir. Enregistrez le graphe en tant que recette lorsqu'il devient utile de le répéter, de le réviser ou de le partager.
Une recette de workflow est un fichier JSON ou YAML qui déclare des entrées et une arborescence de nœuds. Stockez les recettes du projet dans .kiro/workflows/ avec l'un de ces suffixes :
*.workflow.json*.workflow.yaml*.workflow.ymlKiro découvre ces fichiers à l'exécution. Si des fichiers ayant le même radical utilisent plusieurs suffixes pris en charge, le fichier JSON a priorité et Kiro signale l'autre fichier comme un conflit.
Stockez les recettes personnelles qui doivent être accessibles dans plusieurs espaces de travail dans ~/.kiro/workflows/. L'ordre de priorité des noms de recettes est le suivant : projet, utilisateur, recettes de compte synchronisées, puis recettes intégrées. Une recette non valide de priorité supérieure ne masque pas une recette valide de priorité inférieure. Les recettes synchronisées et intégrées disponibles peuvent varier selon le compte et la version du client.
Dans Kiro Web, téléversez une recette prise en charge depuis Paramètres → Workflows. Pour importer un dossier .kiro/workflows/ complet, utilisez Configuration Sync.
Créez .kiro/workflows/plan-and-implement.workflow.json :
{ "name": "plan-and-implement", "description": "Plan a change, then implement it", "inputs": { "task": "prompt" }, "steps": [ { "type": "step", "id": "plan", "agent": "wf-planner", "prompt": "Create an implementation plan for: {{task}}. Do not edit files." }, { "type": "step", "id": "implement", "agent": "wf-coder", "prompt": "Implement this plan, then run relevant tests:\n\n{{previous.output}}" } ] }
La sortie finale de l'étape plan devient {{previous.output}} pour implement. Avant de lancer la recette, demandez à Kiro de valider la recette enregistrée :
Run `validate_workflow` on `.kiro/workflows/plan-and-implement.workflow.json`. Report every error and warning, and do not launch the Workflow.
Corrigez toutes les erreurs signalées, puis lancez la recette au moyen de votre client. Dans l'IDE, demandez à Kiro dans le clavardage parent d'exécuter la recette enregistrée et décrivez la tâche; ouvrez ensuite Workflows au-dessus du clavardage parent et sélectionnez l'étape plan pour ouvrir son onglet Étape de workflow dédié. Dans la CLI, exécutez /workflow run plan-and-implement --task "Describe the change"; si vous omettez une entrée déclarée, Kiro ouvre un formulaire pour la recueillir. Sélectionnez l'étape plan dans le moniteur pour suivre sa session. Dans Kiro Web, téléversez la recette sous Paramètres → Workflows, demandez à Kiro dans une session infonuagique de l'exécuter et décrivez la tâche, puis ouvrez Workflows et sélectionnez l'étape plan pour la suivre ou lui envoyer un message.
Ces agents sont fournis avec Kiro pour être utilisés dans des recettes. Ils ne sont accessibles aux étapes que lorsque les workflows sont activés et n'apparaissent pas dans le sélecteur /agent; la liste exacte offerte par votre client est celle que Kiro affiche lorsqu'il décrit run_workflow :
| Agent | Rôle |
|---|---|
wf-planner | Investigation et planification en lecture seule; rédige des rapports et des plans |
wf-coder | Met en œuvre les changements, exécute les tests et effectue les commits |
wf-design | Rédige des conceptions techniques |
wf-design-reviewer | Révise une conception par rapport aux exigences |
wf-review-aggregator | Fusionne plusieurs rapports de révision en un seul |
wf-pr-submitter | Ouvre ou réutilise une pull request et consigne son URL |
wf-pr-responder | Répond aux commentaires sur une pull request |
wf-auto-researcher | Propose, applique et mesure une expérience par itération |
wf-workflow-creator | Rédige une recette à partir d'une description de tâche; utilisé par l'orchestrateur, et non dans vos étapes |
semantic_reviewer | Révision comportementale du code; enregistré à la fois comme agent d'étape de workflow et comme sous-agent général |
L'accès aux outils d'une étape provient de la définition de son agent, y compris ses paramètres tools et excludedTools. Utilisez des agents à portée restreinte pour les étapes sans surveillance et examinez les autorisations associées à chaque agent avant de lancer la recette.
| Champ | Obligatoire | Description |
|---|---|---|
name | Oui | Nom stable de la recette |
description | Non | Objectif affiché par les sélecteurs de recettes |
inputs | Non | Mappage des noms d'entrée vers des indications de type de forme libre comme prompt, file ou string; la valeur par défaut est {} |
modelId | Non | Modèle par défaut des étapes; auto ou l'omission hérite de la session parent |
effortLevel | Non | Effort de raisonnement par défaut des étapes |
steps | Oui | Tableau de nœuds de workflow; les nœuds de premier niveau s'exécutent dans l'ordre |
Les indications de type d'entrée aident une interface de lancement à recueillir les valeurs, mais Kiro ne les impose pas à l'exécution. Définissez chaque variable de modèle simple dans inputs et fournissez chaque valeur au lancement.
Une recette est une arborescence. Le tableau steps racine est une séquence implicite; les conteneurs s'imbriquent pour composer le flux de contrôle, tandis que les nœuds step et watch sont les feuilles qui accomplissent le travail.
| Type | Objectif | Champs obligatoires |
|---|---|---|
step | Exécuter un agent nommé dans sa propre session | id, agent, prompt |
sequence | Exécuter les nœuds enfants dans l'ordre | id, steps |
repeat | Exécuter les nœuds enfants jusqu'à ce qu'une condition corresponde ou qu'un plafond soit atteint | id, steps, maxIterations, onMaxIterations |
parallel | Planifier des branches indépendantes et joindre leurs résultats | id, branches, joinPolicy |
watch | Interroger un système externe au moyen d'un gestionnaire sans utiliser de tours de modèle pendant l'inactivité | id, handler, config |
L'arborescence ci-dessous place un nœud de chaque type dans une petite recette générique. Sélectionnez une ligne pour voir le comportement de ce type à l'exécution; les badges sont les mêmes que ceux utilisés dans toutes les figures suivantes. Le badge gate n'est pas un type de nœud : il indique une stopCondition, soit la vérification qu'une répétition évalue après chaque itération, décrite sous Définir les conditions d'arrêt.
A recipe is a tree of executable leaves and containers
Select any row to inspect the fields and runtime rule behind it.
indentation and trunk lines encode parent-child relationships; badges identify executable leaves, recursive containers, and the conditions that let a repeat exit or a step complete; the detail pane follows the selected row
Chaque id de nœud doit être unique dans la recette statique. Une recette peut contenir au plus 50 nœuds step et imbriquer les nœuds jusqu'à une profondeur maximale de 8. Les itérations de répétition n'utilisent pas d'emplacements d'étape statiques supplémentaires.
Une step prend en charge les champs facultatifs suivants en plus de id, agent et prompt :
| Champ | Comportement |
|---|---|
artifacts | Associe des noms logiques aux fichiers produits par l'étape |
captureOutput | Capture le dernier message de l'assistant de l'étape pour les modèles ultérieurs; la valeur par défaut est true |
completion | Maintient l'étape interactive jusqu'à ce qu'une condition d'arrêt corresponde |
modelId | Remplace le modèle du workflow et de la session parent |
effortLevel | Remplace l'effort de raisonnement du workflow et de la session parent |
Faites du livrable demandé la réponse finale de l'étape. C'est cette réponse que {{step-id.output}} et {{previous.output}} transmettent en aval.
Un agent d'étape signale son résultat en appelant l'outil send_message. L'outil publie une courte note dans la session parent, et sa valeur severity sert également de signal de cycle de vie de l'étape :
severity | Signal enregistré | Effet sur l'étape |
|---|---|---|
success | success | L'étape se termine; la sortie est capturée; le workflow avance |
warning | need_input | L'étape et l'exécution sont mises en pause pour obtenir une entrée de l'utilisateur; l'étape reste en pause après chaque tour jusqu'à ce qu'elle signale success ou error |
error | error | L'étape échoue; l'échec se propage dans l'arborescence |
info | aucun | Note de progression seulement; aucun effet sur le cycle de vie |
Kiro injecte automatiquement ce protocole dans chaque session d'étape, vous n'avez donc pas à l'expliquer dans votre requête. Il est toutefois utile d'indiquer à l'agent quand envoyer le signal, par exemple « Terminez avec send_message et la valeur success pour severity une fois que les tests réussissent. » Un tour qui se termine sans appel à send_message et sans condition completion non satisfaite termine l'étape.
send_message est la moitié sortante d'un canal bidirectionnel : des directives peuvent aussi parvenir à une étape pendant son exécution ou son attente. Rédigez des requêtes qui laissent place à ces directives plutôt que de supposer que l'étape s'exécute sans surveillance; consultez Répondre quand une étape a besoin d'une entrée.
Utilisez des artéfacts lorsqu'un fichier constitue le transfert durable :
{ "type": "step", "id": "design", "agent": "wf-planner", "prompt": "Write the design for {{task}} to .kiro/workflow-output/design.md.", "artifacts": { "design": ".kiro/workflow-output/design.md" } }
Une étape ultérieure peut référencer le chemin enregistré comme {{artifacts.design}}. Les chemins d'artéfact relatifs sont résolus à partir de la racine principale de l'espace de travail.
Chaque valeur qu'une étape peut lire arrive au moyen d'un modèle {{...}}. Les entrées proviennent du lancement, les sorties capturées proviennent du dernier message d'une étape précédente ou de la charge utile JSON d'une veille, et les artéfacts proviennent des fichiers déclarés par une étape précédente. Les modèles fonctionnent dans les requêtes d'étape, les chemins d'artéfact, les chemins de fichier des conditions d'arrêt et les valeurs de chaîne dans la config d'un nœud watch.
La requête assure le câblage. Choisissez une étape ci-dessous pour voir toutes les valeurs qu'elle lit, l'étape qui a produit chacune d'elles et ce qu'elle publie pour les étapes ultérieures. Faites reculer l'exécution avec le transport : une valeur dont le producteur n'a pas encore terminé devient ambre, ce qui illustre la règle d'ordre expliquée dans le reste de cette section :
Select a step to see what it reads and writes. Step back through the run to catch a value before its producer has finished.
plannot started · wf-planner
reads
{{task}}launch input{{run_dir}}launch inputwrites
{{plan.output}}read by implement{{artifacts.plan}}read by implement01Launch. You supply the task and run directory as declared inputs.
the tree on the left is the recipe structure; the list on the right names every value the selected step reads and where it comes from, then what it writes and who reads it. A value whose producer has not finished shows in amber
| Forme | Valeur |
|---|---|
{{previous.output}} | Sortie capturée du dernier frère terminé dans le même conteneur |
{{step-id.output}} | Sortie capturée d'une step ou d'une watch antérieure, selon son ID |
{{steps.step-id.output}} | Alias hérité de {{step-id.output}} |
{{artifacts.name}} | Chemin enregistré sous name par une étape antérieure |
{{input-name}} | Entrée de lancement déclarée dans inputs |
Les références structurées doivent pointer vers un producteur qui s'exécute avant le consommateur. Elles font échouer l'étape consommatrice si Kiro ne peut pas les résoudre. En particulier :
{{previous.output}} dans le premier nœud d'un conteneur.{{previous.output}} dans une branche parallèle; l'ordre des branches n'est pas garanti.Les entrées simples inconnues se comportent différemment. {{unknown}} demeure du texte littéral et produit un avertissement de validation plutôt qu'une erreur. Kiro ne fournit aucune variable implicite. Chaque {{name}} simple doit être déclaré dans inputs et fourni au lancement.
Utilisez sequence pour nommer et regrouper les nœuds qui doivent s'exécuter dans l'ordre. Le tableau steps racine est déjà une séquence implicite; ajoutez donc une sequence explicite seulement lorsque l'imbrication clarifie le plan.
Une répétition exécute toujours son corps au moins une fois. Après chaque itération terminée, Kiro évalue la condition d'arrêt; une correspondance termine la répétition avant le début d'une autre itération. Pour fileCheck, Kiro lit le fichier JSON à path et compare la valeur à jsonPath avec value. Les chemins relatifs sont résolus à partir de la racine principale de l'espace de travail. Un fichier manquant ou illisible, un JSON non valide, un chemin JSON manquant ou une valeur différente ne correspond pas, de sorte que la répétition continue.
{ "type": "repeat", "id": "implementation-loop", "maxIterations": 10, "onMaxIterations": "pause", "stopCondition": { "fileCheck": { "path": ".kiro/workflow-output/status.json", "jsonPath": "complete", "value": true } }, "steps": [ { "type": "step", "id": "implement-next-item", "agent": "wf-coder", "prompt": "Implement the next incomplete item and update .kiro/workflow-output/status.json." } ] }
Une répétition peut omettre à la fois stopCondition et stopWhen; elle s'exécute alors jusqu'à maxIterations.
Choisissez ce qui se produit lorsque le plafond est atteint :
onMaxIterations | Résultat |
|---|---|
abort | Abandonner la répétition et l'exécution |
continue | Terminer la répétition et passer au frère suivant |
pause | Mettre en pause pour obtenir une décision humaine |
La reprise d'une répétition mise en pause à son plafond n'ajoute pas d'itérations; elle se remet immédiatement en pause. Révisez le plan restant ou arrêtez l'exécution et lancez la définition corrigée en tant que nouvelle exécution.
Un nœud parallèle planifie chaque branche indépendamment :
{ "type": "parallel", "id": "reviews", "joinPolicy": "allSettled", "branches": [ { "type": "step", "id": "security-review", "agent": "semantic_reviewer", "prompt": "Review the current changes for security issues." }, { "type": "step", "id": "test-review", "agent": "semantic_reviewer", "prompt": "Review the current changes for missing tests." } ] }
Trois politiques déterminent quand le nœud parallèle se stabilise et si l'échec d'une branche annule ses frères : all, allSettled et any. Une branche en pause n'annule jamais ses frères; une branche peut être mise en pause lorsque, par exemple, une répétition imbriquée atteint onMaxIterations: "pause". Choisissez une situation ci-dessous pour voir comment chaque politique la résoudrait; la différence réside dans le moment et l'annulation.
Two branches. What should the parent do when…
branch 1 failedbranch 2 running
allfailed nowreports the failure immediately and cancels branch 2allSettledstill runningwaits for branch 2 to finish, then reports failed with every result keptanystill runningbranch 2 can still complete and rescue the parentUse all when one failure makes the rest pointless. Use allSettled when you need every branch's evidence, such as independent reviews. Use any when the first good result is enough.
pick what happened to the two branches; each line shows how one joinPolicy resolves it, including which siblings it cancels
Les étapes interactives avec completion ne peuvent pas être imbriquées dans parallel.
Un nœud watch interroge un système externe au moyen d'un gestionnaire sans utiliser de tours de modèle lorsqu'il n'y a aucun changement. Lorsque le gestionnaire signale une nouvelle activité, sa charge utile JSON devient {{watch-id.output}} pour l'étape suivante. Un résultat terminal demeure mémorisé pour stopWhen: "watch-id.terminal". Deux gestionnaires sont intégrés : github-pr surveille une pull request, et command exécute un programme que vous écrivez, de sorte qu'un workflow peut attendre tout ce qu'un script ou une CLI peut lire.
idleTimeoutSec se trouve sur le nœud de veille lui-même, et non dans config, et s'applique aux deux gestionnaires. Lorsqu'il est défini, une veille qui demeure inactive pendant ce nombre de secondes se termine avec un résultat terminal et sa sortie devient {"outcome": "idle-timeout", "idleTimeoutSec": <seconds>}, de sorte que stopWhen: "watch-id.terminal" se déclenche et que toute étape suivante s'exécute quand même; rédigez la requête de cette étape afin qu'elle traite aussi bien une expiration que l'activité réelle. L'horloge d'inactivité redémarre chaque fois qu'une répétition revient à la veille, et le maxIterations de la répétition ne limite pas les interrogations inactives dans une même entrée. Si la valeur n'est pas définie, la veille attend indéfiniment.
Pointez le gestionnaire vers une URL ou vers un fichier JSON de l'espace de travail dont le champ url de premier niveau contient l'URL de la pull request. La forme de fichier est le modèle habituel lorsqu'une étape précédente ouvre la pull request et enregistre son emplacement :
{ "type": "watch", "id": "wait-for-pr", "handler": "github-pr", "config": { "prRef": ".kiro/workflow-output/pr.json", "pollIntervalSec": 60 }, "idleTimeoutSec": 3600 }
Champ config | Objectif |
|---|---|
prRef ou url | L'un est obligatoire : un fichier JSON de l'espace de travail avec un champ url de premier niveau, ou directement l'URL de la PR |
pollIntervalSec | Cadence d'interrogation; valeur par défaut 60, minimum 30 |
includeOwnActivity | Permettre aux commentaires de l'identité gh authentifiée de réveiller la veille; valeur par défaut false |
ignoreAuthors | Identifiants de connexion dont l'activité ne réveille jamais la veille, comme un robot qui réécrit un commentaire marqueur |
commandTimeoutSec | Délai d'expiration facultatif pour chaque appel gh sous-jacent |
La veille signale terminal-state lorsque la PR est fusionnée ou fermée. Lors d'une nouvelle activité, {{wait-for-pr.output}} est un objet JSON sur lequel votre requête de réponse peut compter; chaque clé est toujours présente :
{ "url": "https://github.com/org/repo/pull/42", "state": "OPEN", "newComments": [], "newReviews": [], "inlineComments": [], "excludedComments": [], "excludedReviews": [], "excludedInlineComments": [], "inlineCommentsFetch": "ok", "backlog": { "remaining": 0 }, "headSha": "4b715b8b", "newFailedChecks": [], "passingCheckCount": 12, "pendingCheckCount": 3 }
state vaut OPEN, MERGED ou CLOSED. Les tableaux new* contiennent l'activité non vue qui a réveillé la veille; les tableaux excluded* contiennent l'activité non vue des auteurs ignorés, à titre contextuel seulement. Chaque élément réveille la veille au plus une fois; les modifications et les suppressions ne la réveillent pas. La livraison est limitée à 10 éléments pouvant provoquer un réveil par interrogation, du plus ancien au plus récent; tout élément excédentaire est traité lors d'interrogations ultérieures et compté dans backlog.remaining. La charge utile terminale est exemptée de cette limite et contient tous les éléments restants.
Un échec de vérification CI réveille également la veille. headSha est le commit de tête sur lequel les vérifications ont été exécutées, ou null s'il est inconnu. Chaque entrée newFailedChecks comprend name, workflowName, conclusion, detailsUrl, runId, startedAt et completedAt, et un échec est signalé une fois par commit de tête, nom de vérification, URL de détails et heure d'achèvement, de sorte qu'une vérification qui reste en échec ne réveille pas la veille à chaque interrogation, tandis qu'une nouvelle tête ou une nouvelle exécution le fait. Les vérifications en échec ne sont jamais limitées, et une vérification Actions en échec est retenue jusqu'à la fin de son exécution afin qu'un seul réveil transmette tous les échecs de cette exécution. passingCheckCount et pendingCheckCount résument le reste; les vérifications ignorées, annulées, neutres et périmées ne comptent dans aucun des deux. Lorsqu'un répondant a besoin de tous les détails des vérifications, demandez-lui d'exécuter gh pr view <url> --json statusCheckRollup.
Après une interruption et une récupération, la livraison est effectuée au moins une fois; rédigez donc des requêtes de réponse qui tolèrent un élément répété.
Les chemins prRef sont confinés aux racines de l'espace de travail de la même façon que les chemins fileCheck. Kiro valide la configuration du gestionnaire lors de la création de l'exécution; l'outil autonome validate_workflow ne peut pas effectuer cette vérification dépendante du registre.
Utilisez handler: "command" lorsqu'un script ou une CLI peut vous indiquer si quelque chose a changé : un ticket dans votre système de suivi des problèmes, un déploiement, une compilation dans un autre système CI ou une révision dans un outil sans gestionnaire intégré. Kiro démarre votre programme une fois par interrogation; le programme vérifie les changements, imprime un résultat et se termine. Un résultat inactif maintient l'interrogation de la veille sans tour d'agent. Un résultat de nouvelle activité ou d'état terminal termine cette entrée de veille, et l'étape suivante lit la charge utile dans {{watch-id.output}}.
{ "type": "watch", "id": "review", "handler": "command", "config": { "command": "node watch-review.mjs", "reviewFile": "mock-review.json", "pollIntervalSec": 10, "commandTimeoutSec": 5 } }
Champ config | Objectif |
|---|---|
command | Obligatoire. Une ligne de commande statique, exécutée par l'interpréteur de commandes par défaut de la session dans l'espace de travail de l'exécution |
pollIntervalSec | Cadence d'interrogation; valeur par défaut 60, minimum 10 |
commandTimeoutSec | Délai d'expiration facultatif par interrogation en secondes; positif, sans minimum |
| tout autre champ | Vos propres clés, transmises au programme en tant que données |
Règles associées à ces champs :
$SHELL ailleurs.command. Il n'existe aucune clé args, et une config qui en contient une est rejetée. Un modèle {{...}} n'importe où dans command est rejeté lors de la soumission.commandTimeoutSec non définie permet à une interrogation d'attendre indéfiniment. Une expiration termine toute l'arborescence de processus de la commande et compte comme une interrogation inactive avec l'ancien curseur; réglez-la donc assez longtemps pour le travail d'une interrogation. Le idleTimeoutSec du nœud est vérifié entre les interrogations et n'interrompt pas une commande bloquée.Chaque interrogation écrit un objet JSON dans l'entrée standard du programme, puis la ferme. config contient toutes les clés de configuration de veille sauf command; workspacePath est l'espace de travail principal et le répertoire de travail du processus; additionalDirectories répertorie les autres racines d'espace de travail. La première interrogation d'une exécution a cursor: null.
{ "cursor": null, "config": { "reviewFile": "mock-review.json", "pollIntervalSec": 10, "commandTimeoutSec": 5 }, "workspacePath": "/path/to/project", "additionalDirectories": [] }
Le programme écrit exactement un objet JSON dans la sortie standard et se termine avec le code 0 :
{ "outcome": "new-activity", "cursor": { "revision": 1 }, "payload": "{\"state\":\"OPEN\",\"summary\":\"Please add a test.\"}" }
outcome vaut idle, new-activity ou terminal-state.cursor est obligatoire et peut être n'importe quelle valeur JSON, y compris une valeur null explicite; il ne doit jamais être omis. Kiro le stocke de manière opaque, y compris lors des interrogations inactives, le retransmet à l'interrogation suivante, le transporte entre les itérations de répétition et le restaure à la reprise d'une exécution. Votre programme décide ce qui est nouveau; Kiro ne compare jamais les charges utiles ou les ID d'événement, et une nouvelle exécution commence à null.payload est une chaîne facultative. Utilisez JSON.stringify lorsque l'étape suivante a besoin de données structurées, et fournissez-la pour les résultats new-activity et terminal-state; une charge utile inactive n'est pas capturée.targetId est une chaîne stable facultative qui nomme la ressource surveillée. Kiro l'utilise pour dériver une étiquette d'exécution lorsqu'aucune n'a été fournie, et non pour dédupliquer les événements.Les codes de sortie déterminent la signification d'une interrogation en échec. Le code 0 avec un résultat valide constitue le résultat de l'interrogation; le code 0 avec du JSON malformé, une valeur outcome non valide ou un cursor manquant fait échouer le nœud de veille. Le code 2 fait échouer le nœud en raison d'une entrée non valide, et les codes 126 et 127 le font échouer parce que l'interpréteur de commandes n'a pas pu exécuter ou trouver le programme, de sorte qu'aucune interrogation ultérieure ne réussirait. Tout autre code de sortie non nul, y compris l'arrêt par commandTimeoutSec, est une interrogation inactive; un programme temporairement indisponible réessaie donc à l'interrogation suivante. PowerShell ne préserve pas ces codes réservés; sous Windows, ils peuvent être reçus comme un code non nul générique et maintenir l'interrogation de la veille. Mettez-y donc fin au moyen du résultat : retournez terminal-state avec une charge utile explicative et le code de sortie 0.
Chaque lancement est soumis à la politique d'autorisation de la session qui a lancé l'exécution. Une règle qui demande une autorisation envoie la demande à cette session, et un refus fait échouer le nœud de veille; la mise en pause ou l'annulation de la veille retire une demande ouverte, de sorte qu'une réponse tardive n'a aucun effet. La ligne de commande s'exécute comme une commande execute_bash pour cette session : dans son bac à sable lorsqu'il est actif, et pas du tout lorsqu'un bac à sable configuré ne peut pas être préparé, auquel cas le nœud échoue avec la raison au lieu de s'exécuter sans confinement. Une exécution dont la session de lancement n'est pas chargée l'attend, en se mettant en pause avec le code de détail ParentSessionUnavailable, puis reprend d'elle-même lorsque la session est chargée; la suppression de la session de lancement fait échouer le nœud.
Gardez la sortie standard exempte de journaux, de bannières et de messages de progression, y compris la sortie de toute CLI appelée, et envoyez les diagnostics à la sortie d'erreur standard; ne placez d'informations d'identification dans aucune des deux. Kiro n'impose aucune limite d'octets aux flux, au curseur ou à la charge utile, ni aucune limite d'éléments; limitez-les donc dans votre programme : la charge utile est stockée avec l'exécution et peut entrer dans la requête de l'agent suivant. Pour un flux d'événements réel, retournez un petit lot ainsi que des ID ou une référence de fichier pour le reste, et avancez le curseur seulement au-delà des éléments livrés ou délibérément exclus. Après une interruption, la livraison est effectuée au moins une fois; le répondant doit donc tolérer les doublons.
L'exemple ci-dessous ne nécessite aucun réseau. Enregistrez cet instantané sous mock-review.json dans votre espace de travail; revision est un compteur que vous augmentez chaque fois que le résumé ou l'état change :
{ "revision": 1, "state": "OPEN", "summary": "Please add a test." }
Enregistrez le programme de veille sous watch-review.mjs à côté de celui-ci. Il signale l'instantané à la première interrogation, reste inactif tant que la révision ne change pas, signale une révision plus élevée comme une nouvelle activité et signale un état autre que OPEN comme terminal :
import { readFile } from 'node:fs/promises'; import { resolve } from 'node:path'; try { let input = ''; for await (const chunk of process.stdin) input += chunk; const { cursor, config, workspacePath } = JSON.parse(input); const review = JSON.parse( await readFile(resolve(workspacePath, config.reviewFile), 'utf8') ); const seen = cursor?.revision ?? 0; let result = { outcome: 'idle', cursor }; if (review.state !== 'OPEN' || review.revision > seen) { result = { outcome: review.state === 'OPEN' ? 'new-activity' : 'terminal-state', cursor: { revision: review.revision }, payload: JSON.stringify({ state: review.state, summary: review.summary }) }; } process.stdout.write(JSON.stringify(result) + '\n'); } catch { process.stderr.write('Invalid input or unreadable review file\n'); process.exitCode = 2; }
Testez-le manuellement avant de l'intégrer à une recette : enregistrez l'objet d'entrée standard ci-dessus dans poll-input.json avec le chemin absolu de votre espace de travail, puis exécutez node watch-review.mjs < poll-input.json dans un interpréteur POSIX, ou Get-Content -Raw poll-input.json | node watch-review.mjs dans PowerShell. La première interrogation imprime le résultat new-activity affiché précédemment. Copiez {"revision":1} dans le cursor de l'entrée et exécutez de nouveau le programme : il imprime {"outcome":"idle","cursor":{"revision":1}}. Faites passer l'instantané à la révision 2 et exécutez-le une fois de plus avec la même entrée; le curseur avance avec le nouveau résumé dans la charge utile. Un programme de veille réel doit distinguer une mauvaise configuration (code de sortie 2) d'une défaillance temporaire de service (tout autre code de sortie non nul), ce dont cet exemple local n'a pas besoin.
Placez la veille et son répondant dans une repeat, avec stopWhen sur la répétition plutôt que sur la veille. Le répondant s'exécute également pour la charge utile terminale, car la répétition vérifie stopWhen après la fin de son corps :
{ "name": "mock-review-watch", "steps": [ { "type": "repeat", "id": "review-loop", "maxIterations": 5, "onMaxIterations": "pause", "stopWhen": "review.terminal", "steps": [ { "type": "watch", "id": "review", "handler": "command", "config": { "command": "node watch-review.mjs", "reviewFile": "mock-review.json", "pollIntervalSec": 10, "commandTimeoutSec": 5 } }, { "type": "step", "id": "respond-to-review", "agent": "wf-coder", "prompt": "Summarize this mock review without changing files. If MERGED or CLOSED, report that it is finished.\n\n{{review.output}}" } ] } ] }
Réglez l'état de l'instantané sur MERGED et augmentez sa révision pour exercer le résultat terminal et observer l'arrêt de la boucle.
Les lignes gate dans l'arborescence des types de nœuds ci-dessus sont des objets stopCondition. Utilisez stopCondition sur une répétition ou comme valeur completion d'une étape. Lorsqu'un objet contient plusieurs champs, une seule correspondance suffit à arrêter la boucle ou à terminer l'étape.
| Champ | Correspond lorsque |
|---|---|
containsText | La dernière sortie capturée contient le texte indiqué |
completionSignal | Le dernier signal d'étape est success, need_input (envoyé comme send_message avec la valeur warning pour severity) ou error |
fileCheck | Une valeur JSON à jsonPath est strictement égale à value |
Un chemin fileCheck hors de toutes les racines d'espace de travail autorisées fait échouer le nœud.
Si value est un tableau, Kiro le traite comme une liste de valeurs possibles. Placez un tableau littéral dans un autre tableau :
{ "fileCheck": { "path": "result.json", "jsonPath": "labels", "value": [["ready", "reviewed"]] } }
Une répétition peut utiliser stopWhen au lieu de stopCondition :
{ "stopWhen": "wait-for-pr.terminal" }
{ "stopWhen": "{{aggregate.output}} contains VERDICT: APPROVED" }
Ne définissez pas les deux formes sur la même répétition.
Chaque étape résout son modèle et son effort dans l'ordre suivant :
Utilisez modelId: "auto" ou omettez modelId pour hériter. Les valeurs d'effort dépendent du modèle sélectionné. Une valeur d'effort non prise en charge est ajustée à la valeur par défaut de ce modèle lors de la création de la session d'étape; un modèle inconnu passe la validation avec seulement un avertissement, puis échoue au premier appel de modèle de l'étape sans solution de repli, de sorte qu'un ID de modèle deviné fait échouer l'exécution en cours de route.
Choisissez des configurations adaptées au rôle de chaque étape :
La forme du workflow et le choix du modèle peuvent être testés ensemble. Exécutez le même ensemble de tâches au moyen de graphes plan → execute → verify différents, consignez la qualité, le temps écoulé et l'utilisation estimée comme artéfacts, puis comparez-les avec un évaluateur déclaré. Un modèle qui donne de bons résultats avec une requête générale peut se comporter différemment lorsque le travail est décomposé en étapes de planification, d'exécution, de critique et de révision.
Ne supposez pas une sélection automatique du fournisseur, une solution de repli ou une optimisation des performances. La disponibilité du fournisseur, du modèle et de l'effort varie selon le compte et le client. Validez chaque modelId avant le lancement et consultez Modèles disponibles pour connaître les options publiques actuelles. Les exemples de workflows présentent la forme de comparaison.
Après avoir enregistré la recette JSON ou YAML complète, demandez à Kiro d'exécuter validate_workflow sur le fichier avant de le lancer. L'outil signale les contraintes de chargement que la recette enfreint, notamment :
stopWhen malformées;Un résultat réussi ne prouve pas que l'exécution peut commencer. Le validateur autonome ne peut pas rejeter le nom d'un agent personnalisé inconnu ni valider la disponibilité et la configuration du gestionnaire de veille à l'exécution. Kiro effectue ces vérifications lorsqu'il crée l'exécution.
maxIterations finie pour chaque répétition et choisissez délibérément le comportement au plafond.
Créer des workflows