Que fait Orchestrateur Parallèle de Tâches ?
Appliquez cette compétence à chaque tâche, y compris les questions, l'écriture, la révision, la planification et l'implémentation. Réutilisez le point d'entrée chargé au sein d'une session ; ne relisez pas les instructions inchangées et ne redécouvrez pas les ressources à chaque message. Le workflow est comprendre, évaluer, planifier, router, exécuter, checkpoint, intégrer, vérifier, rapporter, avec décomposition et parallélisme uniquement lorsque c'est utile. Un orchestrateur principal possède le brief de travail, l'intégration et la réponse finale.
Restez indépendant de la cible. Découvrez la cible active, les outils et les conventions de chemin au moment de l'exécution. Gardez les liens vers les ressources de cette compétence relatifs ; résolvez les chemins des tâches opérationnelles par rapport à la cible active, jamais vers le répertoire d'installation de la compétence. Créez des données d'orchestration locales à la cible uniquement lorsque le niveau de persistance sélectionné l'exige.
La même politique s'applique dans Codex, Claude Code, Cursor, Antigravity et d'autres agents compatibles, quel que soit le LLM serveur. Utilisez les contrôles documentés de l'hôte actif, pas les noms d'arguments d'un autre fournisseur. Pour l'installation sur différents hôtes ou appareils, utilisez references/host-integration.md ; ne chargez pas les détails d'installation lors des tâches ordinaires.
Évaluation légère sur chaque tâche
Établissez silencieusement l'intention, l'étape demandée, le périmètre protégé et une vérification suffisante. Classez la tâche et chaque sous-tâche séparément comme TRIVIALE, FAIBLE, MOYENNE, HAUTE ou CRITIQUE, en utilisant le périmètre, les composants affectés, la difficulté de raisonnement, les dépendances, l'ambiguïté, l'impact architectural, le risque de sécurité, la réversibilité, l'effort de recherche et de vérification. La taille du dépôt importe uniquement lorsque la tâche a besoin de ce contexte.
Pour une demande évidente TRIVIALE ou FAIBLE, utilisez l'agent actuel et les outils déterministes selon les besoins, puis répondez. Ne créez pas d'agents, ne scannez pas les CLI installés, ne créez pas de fichiers de gestion, ne générez pas de graphe formel et ne racontez pas l'évaluation. Une demande claire n'a pas besoin de boucle de raffinement. Pour un travail substantiel, enregistrez une raison de complexité compacte et une décision de ressource dans le plan ou le registre existant. Une complexité parent élevée n'implique pas un effort élevé pour chaque enfant.
Avant chaque envoi de sous-agent, y compris celui qui hériterait du parent, appliquez references/resource-routing.md. Réutilisez cette référence après l'avoir chargée. Lorsque l'environnement d'exposition expose des contrôles de modèle et d'effort, sélectionnez et passez les deux explicitement pour la sous-tâche individuelle ; l'omission n'est pas une optimisation. Préférez un contexte ciblé et une route légère suffisante. Un modèle plus fort ou un effort élevé nécessite une raison spécifique à la tâche. Si les contrôles ne sont pas disponibles, enregistrez la limitation plutôt que de prétendre à une sélection. Optimisez d'abord la qualité requise, puis la latence et l'utilisation mesurée ou observable des ressources ; n'inventez jamais d'économies.
Raffinez la demande avant d'agir
Considérez le message de l'utilisateur comme une intention brute. Pour les demandes complexes ou ambiguës, utilisez references/request-refinement.md pour affiner le brief en interne. Inspectez pour résoudre les détails manquants et arrêtez le raffinement lorsque l'instruction est suffisante pour agir et vérifier. Ne retenez que le brief final et les hypothèses matérielles.
Exécutez la boucle silencieusement par défaut ; l'étape d'inspection ci-dessous est la façon dont la plupart des suggestions et questions sont traitées. Allez vers l'utilisateur uniquement lorsqu'il demande à voir ou construire le prompt, ou lorsqu'une question survit à l'inspection et que deux lectures modifieraient sensiblement le livrable, les informations requises ne peuvent pas être inspectées, procéder crée un risque significatif, ou une décision irréversible nécessite son choix. Le raffinement clarifie l'intention. Il ne modifie jamais l'objectif, n'élargit pas le périmètre, n'escalade pas l'étape demandée, et une demande de prompt est fournie comme un prompt, non exécutée.
Choisissez l'exécution directe ou déléguée
Après une inspection minimale, déléguez lorsque au moins deux flux de travail utiles sont prêts pour les dépendances, leurs ensembles d'écriture sont disjoints (lecture seule none est autorisée), et le bénéfice attendu dépasse les frais généraux d'envoi et d'intégration. Une révision indépendante explicite ou une délégation spécialisée peut justifier un travailleur limité. Confirmez que la délégation est disponible et autorisée. Sinon, exécutez directement. L'exécution directe est une utilisation réussie de cette compétence, pas une invocation refusée ; aucune explication de routine n'est nécessaire. Un travail direct avec état peut encore nécessiter un point de contrôle lorsque l'interruption ou les effets externes rendent la récupération matérielle.
Préservez la demande et l'étape
Le prompt révisé terminé est le brief de travail. Il porte l'objectif, le périmètre, les contraintes, le comportement protégé, le livrable attendu, les exigences de preuve, les critères d'acceptation et toutes les hypothèses énoncées, et chaque étape ultérieure décompose, assigne et vérifie par rapport à celui-ci plutôt que par rapport au message original. Préservez toute limite de révision uniquement, de planification uniquement, d'approbation, d'implémentation ou de déploiement. La délégation n'étend pas l'autorisation.
N'utilisez pas des agents parallèles simplement parce qu'ils sont disponibles. La délégation ne modifie jamais l'étape demandée par l'utilisateur ou la limite d'autorisation.
Inspectez avant de décomposer
L'orchestrateur principal inspecte d'abord les instructions applicables du dépôt, l'implémentation actuelle, l'état de l'arbre de travail, les tests pertinents et les preuves fournies. Lisez suffisamment pour identifier les limites architecturales et les fichiers partagés avant d'assigner des modifications. Ne demandez pas aux sous-agents de faire des choix architecturaux indépendants à partir d'un dépôt non inspecté.
Après l'inspection initiale, une découverte en lecture seule limitée peut s'exécuter en parallèle lorsque différentes zones peuvent être examinées indépendamment. Donnez à chaque agent de découverte un chemin ou une question explicite et exigez des preuves plutôt que des résumés larges du dépôt.
Construisez le graphe de tâches
Créez un graphe conscient des dépendances en utilisant les champs dans references/contracts.md. Lisez cette référence lors de la création des paquets de tâches, de l'acceptation des résultats, de la résolution des conflits, de la vérification de l'intégration ou de la préparation du rapport final. Classez chaque nœud comme :
- Parallèle : aucune dépendance non satisfaite et aucune propriété d'écriture qui se chevauche.
- Séquentiel : dépend d'un autre résultat, modifie un contrat partagé ou nécessite d'abord une décision d'intégration.
- Propriété principale : fichiers partagés, architecture, configuration transversale, migrations risquées, intégration finale, ou tout travail qui ne peut pas être délégué en toute sécurité.
Gelez les interfaces et les critères d'acceptation avant l'implémentation en parallèle. Utilisez des chemins absolus pour chaque fichier et périmètre d'instruction. Si deux tâches ont besoin du même fichier ou pourraient prendre des décisions architecturales conflictuelles, assignez un seul propriétaire ou sérialisez-les. La propriété exclusive est appliquée par l'assignation et l'audit de diff, pas par un verrou système de fichiers.
Adaptez la concurrence au travail indépendant utile et à la capacité disponible des sous-agents. Laissez de la capacité pour la coordination lorsque la plateforme compte l'orchestrateur principal dans la limite. Utilisez des vagues lorsque les dépendances ou la capacité empêchent un seul lancement.
Lisez references/state-and-resume.md avant la délégation, le travail direct persistant ou une exécution reprise. Il définit les niveaux de persistance, les points de contrôle, les verrous, la récupération après interruption et l'hygiène des preuves. Gardez les tâches directes simples uniquement dans la conversation.
Assignez un travail limité
Utilisez le contrat d'assignation standard dans references/contracts.md. Chaque assignation doit indiquer :
- un résultat concret et pourquoi il est indépendant ;
- les chemins autorisés et la propriété d'écriture explicite ;
- le contexte pertinent, les contraintes, le comportement protégé et les interfaces gelées ;
- les preuves requises, les tests et le format du résultat ;
- les actions interdites et les conditions d'escalade.
Chaque assignation est elle-même un prompt conçu à partir du brief de travail et tenu au même standard : clair, concis, autonome, un résultat, compréhensible sans la conversation. Donnez uniquement le contexte nécessaire pour ce flux de travail, mais incluez toujours les règles contraignantes et les chemins absolus vers les fichiers d'instructions applicables. N'assiguez pas la même responsabilité à plusieurs agents, sauf si une révision indépendante explicitement demandée justifie la duplication. Les sous-agents ne doivent pas déployer, publier, supprimer des données, modifier les autorisations ou effectuer des actions destructrices sans l'autorisation explicite de l'utilisateur.
Enregistrez l'outil/modèle observé de chaque travailleur, l'effort (ou hérité/indisponible), le contexte ciblé, le budget, la limite de tentatives et la raison de la sélection. Découvrez l'identité CLI externe, le support non interactif, l'authentification et les options de modèle avant de l'utiliser. La simple présence d'un CLI ne prouve rien de tout cela. Suivez le protocole du travailleur externe dans la référence de routage et validez son diff et ses preuves comme tout autre agent.
Exécutez et suivez les vagues parallèles
Choisissez le niveau de persistance et enregistrez la ligne de base de l'arbre de travail avant l'envoi. Émettez chaque tâche prête dans une vague comme des appels indépendants en un tour, avec un budget indiqué. Attendez que la vague entière revienne, échoue ou dépasse le budget avant de commencer le travail dépendant. Ne renvoyez jamais une tâche en cours.
Gardez le registre du thread principal comme faisant autorité et communiquez avec l'utilisateur uniquement à partir du thread principal. Émettez des mises à jour concises lorsque les conclusions ou la progression changent. Un sous-agent qui atteint une limite d'approbation ou architecturale retourne un bloqueur ; il ne peut pas obtenir de consentement. Réévaluez la complexité après de nouvelles preuves et arrêtez d'ajouter des travailleurs lorsque la coordination l'emporte sur le travail utile.
Chaque sous-agent doit retourner le contrat de résultat standard. Dérivez les fichiers modifiés réels à partir du diff du dépôt, pas du rapport de l'agent. Rejetez les affirmations non étayées, les règles contraignantes violées, les preuves manquantes et les modifications hors périmètre. Avant de réessayer, confirmez que le travailleur précédent s'est arrêté, inspectez son périmètre, conservez le travail partiel valide et complétez uniquement ce qui reste. Annulez uniquement une partie invalide attribuable lorsque cela est requis et autorisé. Ne réessayez jamais aveuglément et n'utilisez pas de commandes stash, checkout, reset ou clean à l'échelle du dépôt.
Classez les échecs comme tâche, contexte, outil, modèle ou environnement. Par défaut, un maximum de deux tentatives totales par tâche et une escalade justifiée de modèle/effort dans ce budget. Réparez un paquet déficient ; ne traitez pas l'authentification ou les outils manquants comme un échec de raisonnement. Conservez le travail vérifié des autres travailleurs. Si aucune tentative utile et sûre ne reste, checkpoint le bloqueur et l'action suivante exacte.
Consolidez sous une seule autorité
L'orchestrateur principal examine chaque résultat par rapport à la ligne de base avant la vague et le diff réel. Résolvez les contradictions en vérifiant les preuves du dépôt, les tests et les critères d'acceptation de l'utilisateur. Ne combinez jamais silencieusement des recommandations mutuellement incompatibles.
Suivez la procédure de consolidation et de conflit dans references/contracts.md. L'orchestrateur principal seul :
- accepte ou rejette les modifications de l'agent ;
- intègre les fichiers partagés et le câblage inter-module ;
- réconcilie les contrats, la nomenclature, le comportement et la gestion des erreurs ;
- supprime la duplication et les modifications hors périmètre ;
- vérifie que la fonctionnalité protégée reste intacte.
Vérifiez le résultat intégré
Exécutez l'ensemble de vérification le plus petit et complet qui prouve le comportement demandé et les régressions pertinentes. Incluez des tests ciblés, des tests d'intégration, des vérifications statiques, des builds et des vérifications manuelles ou UI ciblées lorsque applicable. Ne traitez pas les tests d'agents individuels comme une preuve que le résultat combiné fonctionne.
Utilisez la liste de vérification dans references/contracts.md. Marquez chaque vérification matérielle RÉUSSI, ÉCHEC ou Non vérifié. Un échec de vérification requise bloque une revendication d'achèvement.
Rapportez un résultat
Pour le travail direct, donnez le résultat demandé et les limites de vérification matérielles. Pour le travail substantiel délégué ou repris, utilisez le contrat de réponse finale compact dans references/contracts.md ; omettez les sections vides et les transcriptions brutes d'agents.
Invocation et démonstration
Exemple d'invocation :
Utilisez $parallel-task-orchestrator pour ajouter l'export CSV à cette application, mettre à jour les tests et la documentation, conserver le comportement d'export JSON existant et retourner un résultat vérifié.
Pour un exemple multi-agent travaillé et sûr, lisez references/demonstration.md. Pour des exemples de paquets ciblés et de récupération, suivez les liens de references/state-and-resume.md.
Pour les modifications de cette compétence, exécutez les tests d'assistance et les scénarios réalistes dans references/acceptance-tests.md. Séparez les résultats d'assistance déterministes, les exécutions à sec d'agents et l'exécution CLI externe réelle dans les preuves.
Prérequis
L'assistant d'état scripts/state_store.py nécessite Python 3.9+ et le package jsonschema (pip install jsonschema). Tout le reste est constitué d'instructions.