Délégation Parallèle d'Agents

À utiliser pour déléguer du travail à plusieurs sous-agents en un seul appel `delegate_task`, notamment lorsqu'ils créent ou modifient des fichiers.

Qu'est-ce que Délégation Parallèle d'Agents ?

Cette compétence est conçue pour gérer la délégation parallèle de tâches à plusieurs sous-agents, en particulier lorsqu'ils travaillent sur des fichiers dans le même dépôt ou projet. Son objectif principal est d'éviter les conflits (comme deux agents écrivant le même fichier) et les surcoûts, en définissant des règles claires de propriété des chemins. Elle s'applique à tout scénario de déploiement multi-agent touchant le code, qu'il s'agisse de création de fichiers, de refactoring, ou de séquences build-then-test. La procédure décrit comment découper le travail par chemins absolus, exiger des vérifications reproductibles, et gérer les résultats fusionnés. Elle s'appuie sur un fichier modèle de brief (`delegation-brief.md`) pour standardiser les instructions et éviter les malentendus courants (collisions de noms, dérive de conventions, etc.).

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/Apartment38/Agent-Skills/tree/HEAD/autonomous-ai-agents/parallel-agent-delegation

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Délégation Parallèle d'Agents ?

À utiliser pour répartir le travail entre plusieurs sous-agents en un seul appel delegate_task, surtout lorsqu'ils créent ou modifient des fichiers. La plupart des dépassements de coûts et des arbres corrompus ici proviennent du fait que deux agents croient posséder le même fichier.

Quand l'utiliser

Tout déploiement multi-agent où les tâches touchent le même dépôt, répertoire ou projet — création de fichiers, refactorings découpés par domaine, ou séparations build-puis-test.

Procédure

  1. Trancher avant d'expédier, par chemin. Donnez à chaque tâche une propriété exclusive sur des fichiers ou répertoires nommés. Deux agents ne peuvent pas écrire le même fichier, et aucun fichier ne doit rester non attribué. Préférez des tranches moins nombreuses, nettement plus grandes, plutôt que beaucoup de petites qui se chevauchent.

  2. Indiquer les chemins absolus dans chaque brief de tâche. Les chemins relatifs se résolvent par rapport à un répertoire de travail différent à l'intérieur de certains agents, ce qui explique pourquoi un travail atterrit dans ~/fixture au lieu de ~/Projects/app/fixture. Incluez une ligne explicite "ne rien créer en dehors de cet arbre".

  3. Attribuer un seul propriétaire par fichier partagé. Les fichiers de configuration, manifests et registres de listes sont revendiqués par une seule tâche nommée ; dites aux autres qu'ils ne doivent pas l'éditer, seulement rapporter ce qu'il doit contenir.

  4. Interdire les effets secondaires non souhaités. Dites explicitement si les installations, les builds, les exécutions de tests et les commits git sont autorisés. Des installations non supervisées disséminent node_modules dans des répertoires sans rapport.

  5. Demander un rapport vérifiable par machine : chemins absolus exacts créés, ce qui a été vérifié et comment (analysé, rendu, construit, testé unitairement). Un succès auto-déclaré sans méthode de vérification n'est que du bruit.

  6. Vérifier vous-même le résultat fusionné avant de commiter ou de rapporter : build, exécution de la suite de tests, et relecture des fichiers critiques. Ne faites pas confiance au fait que N rapports indépendants composent un arbre fonctionnel.

  7. Balayer les fichiers errants. Cherchez en dehors de l'arbre cible les répertoires que les agents ont pu créer (racine du home, répertoires de projets voisins, scratch). Reconciliez tout ce qui est trouvé avant la fin de la session.

Règles permanentes

  • Les fichiers supprimés sont un symptôme : lorsque deux agents élaguent des chemins "inutilisés", chacun supprime ce que l'autre vient d'écrire. Attribuez les droits de suppression explicitement.
  • Ne bloquez pas votre propre tour en attendant les agents frères ; continuez le travail indépendant et agissez lorsque leurs résultats arrivent.
  • Lorsque les résultats arrivent après que vous avez déjà fini et commité, vérifiez l'état de l'arbre de travail et les fichiers errants, puis décidez ce qui reste à faire — ne présumez pas que l'arbre est propre, ni que leur travail est en conflit.
  • Gardez le nombre d'agents écrivant sur un même artefact aussi bas que possible ; déployez librement pour des analyses en lecture seule, avec parcimonie pour les écritures.

Pièges

  • Collisions de noms partagés. Deux briefs décrivant "les fichiers CSS" ou "la config" mènent à des chemins différents selon les agents ; nommez des chemins absolus exacts.
  • Dérive de convention. Des agents voyant un arbre partiellement construit adoptent la disposition d'un autre en cours de route, laissant deux conventions dans un même projet ; verrouillez la disposition dans le brief.
  • Confiance en une vérification non exécutée. Les rapports affirmant qu'un build ou un rendu a réussi sans preuve signifient généralement qu'il a été jugé structurellement ; reproduisez-le.
  • Collisions de nettoyage. Un agent supprimant ses propres fichiers "maintenant morts" peut supprimer un livrable d'un agent frère — voir la règle permanente ci-dessus.

Fichiers support

  • templates/delegation-brief.md — modèle de brief copiable qui impose la propriété des chemins, les effets secondaires interdits et un format de rapport vérifiable.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

Skills associés