Les tâches Cron exécutent des tâches d'agent selon un horaire. Chaque tâche est une requête en langage naturel plus un horaire; au déclenchement, elle s'exécute dans sa propre session et le résultat est livré à votre message direct Slack et/ou au panneau de notifications du tableau de bord.
Ouvrez le panneau Schedule dans le tableau de bord et cliquez sur Add. Remplissez un nom, la requête et l'horaire (intervalle ou expression cron). Vous pouvez aussi simplement demander dans le clavardage : « Chaque jour de semaine à 9 h, résume mon travail en cours » — l'agent crée la tâche pour vous.
kirocrew cron add "briefing" "give me a morning status report" --cron "0 9 * * 1-5" kirocrew cron add "poll-status" "check the pipeline endpoint" --every 300
L'agent lui-même appelle l'outil MCP équivalent (cron_add) chaque fois que vous dites quelque chose comme « rappelle-moi chaque matin de vérifier… ». Aucune syntaxe à mémoriser.
Le panneau Schedule affiche toutes les tâches avec leur statut, leur prochaine heure d'exécution et des contrôles : mettre en pause, reprendre, déclencher maintenant, modifier, supprimer.
kirocrew cron list kirocrew cron pause <job_id> kirocrew cron resume <job_id> kirocrew cron trigger <job_id> # run once manually kirocrew cron remove <job_id> kirocrew cron remove-all
Toutes ces commandes sont aussi exposées comme outils MCP (cron_list, cron_pause, cron_resume, cron_trigger, cron_remove, cron_remove_all).
| Champ | Signification |
|---|---|
--cron "0 9 * * 1-5" | Expression cron standard |
--every 300 | Toutes les N secondes |
--timezone "America/Los_Angeles" | Fuseau horaire IANA par tâche (par défaut : fuseau horaire de la configuration globale, puis UTC) |
--skip-dates "2026-12-25,2027-01-01" | Exclure des dates locales précises |
Les expressions cron utilisent le format standard à cinq champs : minute, heure, jour du mois, mois et jour de la semaine. La page Schedule affiche l'expression et la prochaine exécution de chaque tâche dans le fuseau horaire de cette tâche.
Lorsqu'une tâche nomme une heure calendaire, fournissez toujours une valeur --timezone explicite. Sans elle, l'expression cron utilise le fuseau horaire de la configuration globale et ne se replie sur UTC que si aucun fuseau horaire global n'est configuré.
| Option | Objectif |
|---|---|
--timeout-secs <n> | Budget de temps par tâche (1800 s par défaut; jusqu'à 24 heures) |
--agent <name> | Agent utilisé pour l'exécution |
--persistent-session | Réutiliser une session entre les exécutions; la valeur persistante est celle enregistrée par défaut |
--silent | Ne livrer rien à moins que la tâche n'envoie explicitement une notification |
--strict-schedule | Désactiver la gigue d'exécution |
Par défaut, les tâches reçoivent un petit délai aléatoire pour répartir le travail simultané. Utilisez --strict-schedule lorsque la minute planifiée exacte est importante.
persistent_session: false via le tableau de bord ou l'outil MCP pour un agent de sondage ou de balayage qui ne doit pas accumuler de contexte antérieur.Pour une tâche d'agent qui n'a pas besoin de l'historique enregistré, activez Minimal context dans le dialogue de création ou de modification de la planification, ou définissez minimal_context: true via l'outil MCP. Crew conserve les instructions de la tâche et les directives requises du membre ou du projet tout en omettant le contexte injecté complet. Cela réduit l'utilisation de jetons sans changer l'agent ni transformer la tâche en script.
Pour une vérification déterministe ne nécessitant pas de raisonnement par modèle, préférez une tâche en script. Demandez au Skill cron-cost-optimize d'inspecter l'historique des exécutions enregistrées et de recommander une exécution en script, en contexte minimal ou en contexte complet. Il fournit des recommandations et ne modifie jamais une tâche lui-même.
La sortie de chaque tâche est livrée à votre message direct Slack (si configuré) et au panneau de notifications du tableau de bord.
Vous pouvez remplacer la livraison par exécution avec des marqueurs deliver: dans la requête ou dans HEARTBEAT.md :
- [ ] Monitor pipeline for failures <!-- deliver:C0123CHANNEL -->
Cela achemine le résultat vers un canal Slack précis au lieu de votre message direct.
Les tâches cron persistent dans ~/.kiro/crew/crons.json et se chargent au démarrage de la passerelle. Tant que la passerelle est en marche, les tâches se déclenchent selon l'horaire.
Si la passerelle est arrêtée au moment où une tâche aurait dû se déclencher, l'exécution planifiée est manquée; Crew ne rejoue pas chaque intervalle manqué au démarrage. Une exécution déjà en cours lorsque la passerelle s'est arrêtée peut redevenir due après le redémarrage car elle n'a pas d'horodatage d'exécution complétée. Vérifiez la page Schedule après un redémarrage inattendu lorsqu'une tâche a des effets externes non idempotents.
Certaines configurations multi-instances ne veulent pas que le planificateur cron soit actif. Démarrez la passerelle avec --no-crons pour l'éviter :
kirocrew gateway --no-crons
Les tâches restent lisibles via kirocrew cron list, mais elles ne se déclencheront pas sur cette instance.
Les tâches cron qui déclenchent le Task Runner n'apparaissent pas dans la page Tasks du tableau de bord — elles sont filtrées pour garder la vue centrée sur le travail initié par l'utilisateur. Les tâches s'exécutent toujours; l'état est simplement caché de la liste visible.
Les exécutions cron sont sans surveillance par définition, donc elles ne portent jamais de confiance par exécution. Tout appel d'outil à l'intérieur d'une tâche cron :
Étendre la confiance par exécution aux exécutions récurrentes n'est délibérément pas prise en charge — l'approbation automatique récurrente est un risque plus grand qu'une seule session interactive.
Les Heartbeats permettent à Crew de surveiller quelque chose au fil du temps sans que vous ayez à surveiller une session. Demandez dans le clavardage — « surveille cette pull request et dis-moi quand des commentaires arrivent » ou « surveille le pipeline et alerte-moi s'il passe au rouge » — et Crew crée une tâche heartbeat qui vérifie toutes les 60 secondes.
Contrairement aux tâches cron (qui exécutent une requête selon un horaire fixe), les Heartbeats sont réactifs — ils ne font apparaître des résultats que lorsque quelque chose change.
Les tâches Heartbeat vivent dans ~/.kiro/crew/workspace/HEARTBEAT.md. Le service heartbeat lit le fichier toutes les 60 secondes, exécute toutes les tâches en parallèle et :
| Heartbeat | Cron | |
|---|---|---|
| Déclencheur | Chaque cycle de 60 s | Horaire ou intervalle fixe |
| Sortie | Seulement quand quelque chose change | À chaque exécution |
| Durée de vie | Jusqu'à ce que la condition soit remplie ou que vous la supprimiez | S'exécute indéfiniment jusqu'à mise en pause/suppression |
| Idéal pour | « Dis-moi quand X se produit » | « Fais Y chaque matin » |
Par défaut, les résultats vont vers votre message direct Slack ou les notifications du tableau de bord. Remplacez cela par tâche avec un marqueur de livraison dans le fichier heartbeat : <!-- deliver:C0123CHANNEL --> achemine vers un canal Slack précis.
Des systèmes externes peuvent déclencher des sessions d'agent Crew via HTTP. Un pipeline d'intégration continue peut aviser Crew lorsqu'une build échoue, ou un outil de surveillance peut escalader une alerte — tout cela sans que personne soit au terminal.
Le point d'accès :
POST /api/hooks/agent Authorization: Bearer <token> Content-Type: application/json { "message": "Build failed for pipeline X. Check logs and report the root cause." }
Les requêtes nécessitent un jeton Bearer valide (générez-en un avec kirocrew token). Jusqu'à 6 sessions webhook simultanées; chacune a un délai d'expiration par défaut de 10 minutes.
Exemple — alerte d'échec d'intégration continue :
curl -X POST http://localhost:5476/api/hooks/agent \ -H "Authorization: Bearer $KIROCREW_TOKEN" \ -H "Content-Type: application/json" \ -d '{"message": "Build failed. Summarize what went wrong."}'
Crew analyse l'échec et répond. Le résultat est acheminé vers votre surface de notification configurée.
Pour les flux de travail persistants qui transportent le contexte à travers plusieurs appels webhook (p. ex. un pipeline à plusieurs étapes), l'agent peut utiliser register_hook pour enregistrer l'état du flux de travail que le prochain appel webhook récupère.
Pour une surveillance qui reste au sein d'une session active (plutôt qu'un heartbeat en arrière-plan), Crew dispose de l'autonudge — une boucle d'autovérification qui réinjecte vos instructions selon une minuterie d'inactivité.
Utilisez-le lorsque vous voulez que Crew continue de vérifier quelque chose dans votre conversation actuelle :
Autonudge fonctionne depuis le clavardage du tableau de bord, les fils Slack et les messages directs Discord. Arrêtez-le en envoyant un nouveau message qui prend le relais de la session, ou avec l'outil autonudge_stop.
Parler à une session de surveillance en cours de boucle ne redémarre plus son compte à rebours, de sorte que les vérifications surviennent au moment prévu. Un incident transitoire, comme une limitation ou une erreur serveur, est réessayé plutôt que comptabilisé en vue de la pause automatique; un cycle réussi réinitialise le compte d'échecs, et une boucle sans surveillance qui perd l'approbation d'un outil le signale au lieu de s'arrêter en silence.
Cron et planification