long-task-coordinator

Vue d’ensemble de la skill long-task-coordinator

Ce que fait long-task-coordinator

long-task-coordinator est une skill de coordination conçue pour les travaux qui doivent survivre aux interruptions, aux relais entre intervenants et aux longues pauses entre deux tours. Sa mission centrale est simple : sortir le travail de longue durée d’une mémoire de chat fragile pour le placer dans un fichier d’état persistant, avec des transitions de statut explicites, des vérifications de reprise et un suivi clair des prochaines étapes.

Pour qui l’installation est pertinente

Cette skill convient particulièrement aux utilisateurs qui font de l’orchestration d’agents, de la recherche déléguée, des migrations, des traitements par lots, ou plus largement toute tâche que l’on peut interrompre, reprendre plus tard ou laisser en attente d’un autre worker. Si votre workflow ressemble souvent à « on reprend ça demain » ou « on délègue puis on reviendra vérifier plus tard », la skill long-task-coordinator est un très bon choix.

Le vrai besoin auquel elle répond

On n’installe pas long-task-coordinator simplement pour « mieux planifier ». On l’installe pour rendre un travail long récupérable et fiable :

• récupérer l’état après une perte de contexte
• suivre clairement les responsabilités entre coordinateur et workers
• représenter explicitement les états d’attente
• éviter les déclarations de fin trompeuses
• reprendre à partir d’une source de vérité enregistrée au lieu d’inférer l’état à partir d’anciens échanges

Ce qui la distingue d’un simple prompt de planification

La différence ne tient pas à une expertise métier. Elle tient à la discipline de workflow :

• un fichier d’état persistant unique
• une boucle fixe : READ -> RECOVER -> DECIDE -> PERSIST -> REPORT -> END
• des statuts explicites comme running, awaiting-result, paused, blocked et complete
• une préférence pour la persistance avant le reporting, afin que la session suivante puisse repartir de manière fiable

Cas d’usage idéaux et cas où elle n’est pas adaptée

Utilisez long-task-coordinator quand la tâche s’étend sur plusieurs sessions, implique des subagents ou des jobs en arrière-plan, ou nécessite des checkpoints et des retries. Évitez-la pour une petite tâche en un seul tour. Le dépôt oriente explicitement les besoins de planification plus légers vers planning-with-files, afin d’éviter la surcharge de coordination quand la reprise n’est pas nécessaire.

Comment utiliser la skill long-task-coordinator

Options d’installation de long-task-coordinator

Le README du dépôt montre une installation manuelle via un lien symbolique de la skill vers le répertoire de skills de votre client, par exemple :

ln -s /path/to/agent-playbook/skills/long-task-coordinator ~/.claude/skills/long-task-coordinator
ln -s /path/to/agent-playbook/skills/long-task-coordinator ~/.codex/skills/long-task-coordinator
ln -s /path/to/agent-playbook/skills/long-task-coordinator ~/.gemini/skills/long-task-coordinator

Si vous utilisez un gestionnaire de skills, vérifiez que le chemin final installé expose bien le contenu réel du dossier skills/long-task-coordinator, et pas seulement la racine du dépôt.

Fichiers à lire en priorité

Pour une prise en main rapide mais fiable, lisez dans cet ordre :

1. skills/long-task-coordinator/SKILL.md
2. skills/long-task-coordinator/references/workflow.md
3. skills/long-task-coordinator/evals/prompts.md
4. skills/long-task-coordinator/README.md

Pourquoi cet ordre fonctionne :

• SKILL.md définit les conditions de déclenchement et les règles essentielles
• references/workflow.md fournit le modèle de fichier d’état réellement exploitable
• evals/prompts.md montre à quoi ressemble un « comportement correct »
• README.md confirme l’installation et la boucle centrale

Les entrées dont la skill a besoin

La skill long-task-coordinator fonctionne mieux si vous fournissez :

• l’objectif de la tâche
• des critères de réussite concrets
• l’indication que le travail est déjà en cours ou non
• l’emplacement du fichier d’état persistant
• les affectations actives de worker ou de subagent
• le prochain déclencheur de checkpoint, par exemple une heure ou une condition
• les blocages ou dépendances déjà connus

Sans ces éléments, le modèle peut quand même démarrer, mais il fera davantage d’hypothèses et produira une coordination moins solide.

Transformer une demande vague en invocation efficace

Demande faible :

Help me keep track of this migration.

Meilleure demande :

Use long-task-coordinator for this migration. Create or recover a durable state file at docs/migration-state.md. Goal: migrate service auth to OAuth2. Success criteria: tests pass, rollout notes written, old auth path disabled. We may hand work to subagents and resume across sessions. If any work is in flight, use an explicit waiting state instead of implying failure.

La version plus solide améliore le résultat, car elle définit dès le départ la persistance, le périmètre, la logique d’achèvement et le mode de coordination.

Créer tôt un fichier d’état persistant

L’habitude opérationnelle la plus importante consiste à créer le fichier d’état avant que le travail ne devienne confus. La référence recommande des chemins comme :

• docs/<topic>-execution-plan.md
• docs/<topic>-state.md
• worklog/<topic>-state.md

Au minimum, enregistrez :

• Goal
• Success criteria
• Status
• Current step
• Completed work
• Next action
• Next checkpoint
• Blockers
• Owners

C’est le point clé d’adoption : si vous sautez le fichier d’état, vous perdez l’essentiel de la valeur de la skill long-task-coordinator.

Utiliser la boucle de reprise à chaque tour

La boucle centrale du dépôt est le cœur pratique de l’usage de long-task-coordinator :

READ -> RECOVER -> DECIDE -> PERSIST -> REPORT -> END

Concrètement, cela signifie :

1. lire d’abord l’état enregistré
2. vérifier si le statut est toujours exact
3. contrôler si le travail délégué est revenu
4. décider s’il faut continuer, attendre, réessayer, mettre en pause ou clôturer
5. écrire l’état mis à jour
6. et seulement ensuite faire un retour à l’utilisateur

C’est cet ordre qui permet à la session suivante de repartir proprement.

Utiliser des statuts explicites, surtout awaiting-result, avec long-task-coordinator

Une fonctionnalité discrète mais très précieuse de cette skill est l’usage de awaiting-result. Beaucoup d’agents donnent une illusion de progression en agissant comme si une tâche déléguée avait échoué ou était terminée alors qu’elle est simplement encore en cours. Cette skill propose un modèle plus propre :

• running pour un travail actif du coordinateur
• awaiting-result lorsqu’un worker ou un job est encore en exécution
• paused lorsqu’on a volontairement interrompu le travail
• blocked lorsque des contraintes externes empêchent d’avancer
• complete uniquement lorsque les critères de réussite sont réellement remplis

Pour l’Agent Orchestration, c’est l’une des distinctions les plus utiles de toute la skill.

Workflow recommandé pour le travail délégué

Un bon mode opératoire ressemble à ceci :

1. définir la tâche et les critères de réussite
2. créer le fichier d’état
3. confier un travail borné à un worker
4. enregistrer le responsable et la condition attendue de retour
5. passer le statut à awaiting-result si l’on attend
6. reprendre à partir de la récupération de l’état, pas de la mémoire
7. mettre à jour les éléments terminés et la prochaine action
8. marquer complete uniquement après vérification des critères

Ce schéma est plus sûr que des prompts ouverts du type « continue » : les relais deviennent auditables.

Modèles de prompts pratiques qui fonctionnent bien

Les bons prompts pour long-task-coordinator incluent généralement un langage de reprise. Exemples :

• “Use long-task-coordinator and recover from any existing state before proposing next steps.”
• “Persist the updated status before reporting.”
• “If a worker is still in flight, mark awaiting-result and define the next checkpoint.”
• “Do not mark complete unless the saved state and success criteria agree.”

Ces formulations s’alignent directement sur les prompts d’évaluation du dépôt et réduisent les faux signaux de certitude.

Erreurs d’adoption fréquentes

La plupart des usages ratés viennent de lacunes de processus, pas d’un manque de fonctionnalités :

• s’appuyer sur l’historique du chat plutôt que sur un fichier
• utiliser des statuts vagues au lieu des états définis
• faire un point d’avancement avant d’avoir mis à jour l’état enregistré
• oublier d’indiquer les responsables du travail délégué
• marquer une tâche comme terminée sans vérifier les critères d’acceptation
• utiliser la skill sur des tâches courtes où la surcharge de coordination n’est pas justifiée

FAQ sur la skill long-task-coordinator

Est-ce que long-task-coordinator vaut le coup pour des tâches simples

En général, non. Si la tâche est courte, tient en une seule session et ne nécessite pas de reprise, long-task-coordinator ajoute une surcharge inutile. Le dépôt la positionne explicitement pour les travaux qui dépassent un tour ou qui dépendent d’un état persistant.

En quoi est-ce différent de planning-with-files

planning-with-files est l’option la plus légère quand vous avez surtout besoin d’une planification structurée. long-task-coordinator sert à gérer la reprise, les états d’attente explicites et la récupération après interruption. Choisissez cette skill lorsque l’intégrité de l’état compte davantage que la simple organisation des étapes.

Est-ce que long-task-coordinator est adapté à l’Agent Orchestration

Oui. C’est même l’un des cas d’usage les plus nets. La skill est conçue pour les configurations coordinateur-worker, l’exécution déléguée, les jobs en arrière-plan et les relais sur plusieurs sessions. Le suivi des responsables et l’état awaiting-result sont particulièrement utiles en Agent Orchestration.

Faut-il un runtime ou un framework spécifique

Non. Le README la décrit comme volontairement abstraite et portable. Elle ne suppose aucun domaine ni runtime particulier. La principale condition est que votre agent puisse lire et écrire un fichier persistant dans le workspace.

Les débutants peuvent-ils utiliser cette skill long-task-coordinator

Oui, à condition qu’ils comprennent déjà la tâche qu’ils coordonnent. La skill elle-même est conceptuellement simple, mais les débutants ont tendance à l’appliquer trop largement. Si vous ne gérez ni interruptions, ni délégation, ni reprise, commencez par une skill de planification plus simple.

Quand ne faut-il pas utiliser long-task-coordinator

Évitez-la si :

• la tâche sera terminée en une seule passe
• il n’est pas nécessaire de reprendre plus tard
• aucun worker délégué ni processus en arrière-plan n’est impliqué
• vous ne voulez pas ajouter l’étape de maintenance d’un fichier d’état

Dans ces cas-là, des prompts ordinaires seront souvent plus rapides.

Comment améliorer la skill long-task-coordinator

Commencer par des critères de réussite plus solides

Le principal levier de qualité, c’est une logique de clôture plus précise. Au lieu de « terminer la migration », écrivez des critères comme :

• les tests d’authentification passent
• la configuration de production est mise à jour
• une note de rollback a été ajoutée
• l’ancien chemin legacy est désactivé

De meilleurs critères rendent beaucoup plus difficile une clôture prématurée de la tâche par le modèle.

Rendre le fichier d’état concret et facile à retrouver

Ne cachez pas l’état dans un fichier temporaire arbitraire. Placez-le dans un chemin prévisible comme docs/oauth-migration-state.md. Une bonne reprise dépend d’un fichier que la session suivante retrouvera réellement sans avoir à deviner.

Enregistrer explicitement les responsabilités

Pour mieux exploiter long-task-coordinator, consignez toujours qui fait quoi :

• Origin: définit la tâche
• Coordinator: maintient l’état et l’enchaînement
• Worker: exécute un travail borné

Cette petite discipline réduit les doublons, les blocages et la confusion quand plusieurs agents participent.

Améliorer les prompts avec des conditions de checkpoint

Un checkpoint faible dit : « reviens voir plus tard ». Un checkpoint solide dit : « reprendre quand le worker a renvoyé les résultats des tests ou à 15:00 UTC, selon le premier des deux événements ». Plus le déclencheur est explicite, moins le coordinateur risque de dériver.

Éviter les faux rapports d’avancement

Un mode d’échec fréquent consiste à produire des comptes rendus fluides mais peu fiables. Corrigez cela en demandant à la skill de :

• lire d’abord l’état enregistré
• vérifier qu’il est toujours exact
• persister les mises à jour avant de résumer
• distinguer l’attente d’un vrai blocage
• justifier complete par rapport aux critères de réussite

Cela permet de garder des sorties long-task-coordinator fiables d’une session à l’autre.

Utiliser les prompts d’évaluation comme tests d’acceptation

evals/prompts.md est utile au-delà d’un simple smoke test. Servez-vous de ces prompts comme d’une checklist locale pour vos propres adaptations :

• peut-elle reprendre un travail interrompu de façon sûre ?
• représente-t-elle honnêtement les états d’attente ?
• prouve-t-elle l’achèvement à l’aide de l’état enregistré ?

Si votre usage personnalisé échoue à ces tests, votre schéma d’orchestration reste encore trop lâche.

Itérer après le premier passage

Après le premier tour de coordination, inspectez le fichier d’état et resserrez tout ce qui reste ambigu :

• remplacer les statuts vagues
• ajouter les responsables manquants
• clarifier les blocages
• découper les prochaines actions trop grosses
• ajouter une vraie condition de checkpoint

La skill long-task-coordinator s’améliore rapidement à mesure que l’état persistant devient plus spécifique, car toutes les reprises futures dépendront de ce fichier plutôt que de la mémoire.