Task Runner

Confiez au Task Runner une spec en markdown et il la décompose en étapes ordonnées, exécute chacune dans sa propre session, teste le résultat, réessaie en cas d'échec et enregistre la progression par points de contrôle. Conçu pour 10 heures ou plus de fonctionnement sans surveillance.

Spec → LLM decomposes → Tasks → Execute → Test → Self-review → Commit or retry

Pour chaque tâche :

1. Nouvelle session (taskrunner:{task_id}:task{N}) avec injection complète de la mémoire
2. Requête construite à partir de la spec + mémoire de travail + état git antérieur
3. L'agent exécute des outils, diffuse la progression en continu et peut appeler des sous-agents
4. Si les tests réussissent, git commite la modification
5. Une session de réviseur indépendante lit le git diff réel et valide le résultat
6. Si la révision échoue, la modification est annulée et on réessaie (jusqu'à 3 tentatives, puis une replanification)

Ouvrez le panneau Projects, décrivez ce que vous voulez dans la zone Compose, affinez-le éventuellement en une spec structurée (✨ Refine), puis cliquez sur Run. La tâche apparaît dans la barre latérale avec la progression en direct, le statut des étapes et des contrôles de pause/annulation.

Vous pouvez aussi téléverser un fichier de spec existant (onglet From Spec) ou demander dans le clavardage : « run this task spec ».

kirocrew run TASK.md              # auto-resume from checkpoint on restart
kirocrew run TASK.md --fresh      # ignore checkpoint, start over
kirocrew run TASK.md --timeout 3600
kirocrew run TASK.md --no-test    # skip test verification

Également disponible via Slack (run <path>) et l'outil MCP task_run.

N'importe quel fichier markdown. Le Task Runner n'est pas exigeant — il décompose ce qui s'y trouve :

# Migrate user service to Go

## Goal
Rewrite the Node.js user service in Go, preserving all behavior.

## Requirements
- Every existing endpoint must continue to work
- Existing tests must pass
- The new implementation must handle the same load

## Acceptance criteria
- `curl` smoke tests pass against a local instance
- All unit tests pass with `go test ./...`
- No behavior change observable from the client

Le LLM décompose ceci en tâches ordonnées avec des dépendances, des critères d'acceptation et des portes d'approbation.

Si vous avez une idée approximative plutôt qu'une spec, utilisez ✨ Compose dans le tableau de bord :

1. Tapez votre idée en langage naturel
2. Cliquez sur ✨ Refine into Spec
3. Le LLM la réécrit en une spec structurée (Goal / Requirements / Acceptance Criteria)
4. Modifiez le résultat avant de l'exécuter

Refine est un appel LLM en une seule fois — sans outils, sans questions de clarification.

Jusqu'à 3 exécutions de tâches concurrentes sont permises (_MAX_CONCURRENT_TASKS). Chacune obtient ses propres :

• task_id — ID résistant aux collisions
• Répertoire de travail — {work_dir}/{spec_stem}/
• Bassin de sessions — chaque étape obtient sa propre session taskrunner:{task_id}:task{N}
• Branche git — kirocrew/task/{task_id} (dans un worktree si un dépôt existe)

Annulez une tâche spécifique avec kirocrew run cancel <task_id>, ou toutes avec kirocrew run cancel.

Les tâches peuvent être mises en pause en cours d'exécution puis reprises plus tard sans perte de progression :

# In the dashboard Tasks panel: Pause button
# In Slack: run pause <task_id>
# REST: POST /api/taskrunner/{task_id}/pause

Reprenez en appelant execute avec fresh=false :

• Les tâches incomplètes sont réinitialisées à PENDING
• Les tâches réussies et ignorées sont conservées telles quelles
• L'exécution se poursuit à partir de la première tâche en attente

Avec fresh=true, toutes les tâches sont réinitialisées — vous repartez du début.

Au redémarrage de la passerelle, toute tâche avec status == "running" passe automatiquement à "paused". Cela évite les tâches zombies qui semblent en cours d'exécution mais n'ont plus de tâche asyncio sous-jacente. Reprenez manuellement depuis le tableau de bord.

Les exécutions sont persistées dans ~/.kiro/crew/tasks/runs.json et rechargées au démarrage.

Les étapes peuvent être marquées avec force_approval: true dans la spec. Ces portes bloquent l'exécution même en mode YOLO :

• La tâche se met en pause à la porte
• Des boutons Approve / Deny intégrés apparaissent dans le tableau de bord
• Vous devez explicitement approuver avant que l'étape ne s'exécute

Utilisez force-approval pour les opérations destructrices (déploiement, suppression, publication, rm -rf).

Chaque tâche s'exécute sur sa propre branche git isolée :

• Dépôt existant — git worktree add crée un répertoire de travail isolé; votre copie de travail reste intacte
• Aucun dépôt — git init dans le répertoire de travail, puis passage à kirocrew/task/{task_id}

Par étape :

• git add -A && git commit après chaque étape réussie
• git reset --hard HEAD~1 en cas d'échec de la révision, avant de réessayer
• git log --oneline + git diff --stat injectés dans la requête de l'étape suivante
• git diff HEAD~1 transmis au réviseur indépendant

L'échec de git init n'est pas fatal — la tâche continue sans coordination git.

Chaque étape passe par un réviseur indépendant utilisant une session distincte (taskrunner:{task_id}:review) :

• Lit le git diff HEAD~1 réel (et non le rapport que fait le LLM sur lui-même)
• Session distincte — aucun biais dû au fait d'avoir écrit le code
• En cas d'échec de la révision : annulation de la modification, nouvelle tentative de l'étape, nouveau commit en cas de succès
• Les exceptions de révision ne sont pas fatales (retourne « passed » pour éviter de bloquer)

Réglez les transitions de statut de l'étape en passant par REVIEWING (visible dans l'interface sous la forme 🔍) avant de promouvoir vers PASSED.

Lorsqu'une étape épuise ses tentatives, le task runner demande au LLM de revoir le plan. Jusqu'à 2 replanifications avant l'échec de l'exécution.

Détection de cycle : 2 erreurs identiques → avertissement; 3 erreurs identiques → étape marquée FAILED avec « Loop detected ». Les incidents de processus ne comptent pas dans ce total.

Les tâches dans la spec peuvent déclarer des dépendances. Les tâches sans dépendances croisées s'exécutent en lots parallèles de 3 (_MAX_PARALLEL_TASKS) :

• Chaque lot s'exécute via asyncio.gather(..., return_exceptions=True)
• Le lot suivant ne démarre qu'une fois le lot en cours terminé
• Les sessions par tâche sont réinitialisées après la boucle

Cela évite des rafales de démarrage à froid de 5N processus de serveur MCP (N tâches parallèles = ~5N processus si non regroupées par lots).

Chaque étape reçoit :

• L'injection complète de ContextBuilder — préférences, projets, historique, mémoire sémantique, leçons, mémoire épisodique, skills déclenchés
• Le texte propre de l'étape comme requête principale
• is_new=True sur le premier message pour que l'injection se déclenche une seule fois, puis les suivis réutilisent le contexte

La détection de blocage sensible à l'activité suit run.last_task_time, mis à jour à chaque fragment de flux, approbation d'outil ou récupération :

La réinitialisation annule la session de l'étape en cours; la nouvelle tentative peut se déclencher à nouveau si elle bloque aussi.

Chaque événement génère une notification préfixée par [spec_name] :

• 🚀 Tâche démarrée
• 📋 Plan prêt (liste des étapes)
• ✅ Étape N/M réussie (titre + aperçu du résultat)
• ❌ Étape N/M échouée (titre + erreur)
• ⚠️ La tâche est peut-être bloquée (minutes depuis la dernière activité)
• 🔄 Replanification (tentative N/2)
• 📝 Leçon apprise
• ✅ Tâche terminée (résumé final avec le temps écoulé et la liste des étapes)

Une fois une tâche terminée, vous pouvez ouvrir son résultat directement dans un nouvel emplacement de clavardage :

POST /api/taskrunner/{task_id}/to-chat

Cela crée une nouvelle session de clavardage préchargée avec la spec de la tâche, le plan et les résultats par étape. À partir de là, vous pouvez poser des questions de suivi ou itérer.

L'état des tâches est projeté dans ~/.kiro/crew/tasks/runs.json avec :

• task_id, spec_path, status, timestamps, error, tokens_used, replan_count
• détails par étape (résultat tronqué à 2 K par étape)

Supprimer une exécution via DELETE /api/taskrunner/{task_id} la retire de la mémoire et du disque.

Le tableau de bord expose un commutateur auto_approve par exécution :

• Désactivé (par défaut) — les demandes de permission d'outil s'affichent de façon interactive
• Activé — les demandes de permission d'outil s'approuvent automatiquement pendant l'exécution

La confiance est limitée par une durée de vie (TTL) (fenêtre du tableau de bord, 6 h max, plafond absolu de 24 h). Chaque appel d'outil auto-approuvé fait avancer l'octroi — une exécution activement en progression ne perd pas sa confiance en cours de route, mais une exécution inactive et abandonnée l'échoit.

Les portes force-approval bloquent toujours. Les listes de refus des Hooks et les blocages de chemins sensibles s'appliquent toujours. auto_approve est délimité de manière stricte et ne s'étend jamais aux exécutions lancées par cron ou par MCP (celles-ci sont sans interface par construction).

Une étape de tâche peut engendrer des sous-agents :

• La session de l'étape hérite de parent_session_key = taskrunner:{task_id}:task{N}
• Les achèvements des sous-agents s'injectent de nouveau dans la session de l'étape
• Le LLM de l'étape peut synthétiser la sortie du sous-agent avant de poursuivre

Cela s'agence bien pour des tâches comme « exécuter cette analyse sur chaque paquet du dépôt » — l'étape se déploie vers des sous-agents, attend le résumé, puis poursuit.

Paramètres liés au task runner :