Orchestration d'essaim
Description
Bonnes pratiques pour lancer, surveiller et gérer des agents de codage externes (Claude Code, Codex, Gemini CLI) via conversation.
Déclencheurs
- swarm
- spawn
- agent
- delegate
- parallel
- coding agent
- claude code
- codex
- gemini cli
Instructions
Essaim vs Organisation
EloPhanto dispose de deux systèmes de délégation. Utilisez le bon :
- Swarm (cette skill) — pour les tâches de codage. Lance des agents externes (Claude Code, Codex, Gemini CLI) dans des worktrees git isolés. Communication unidirectionnelle, éphémère. Utilisez
swarm_spawn. - Organization — pour le travail de domaine (marketing, recherche, design, tout ce qui n'est pas du codage). Lance des clones EloPhanto persistants avec leur propre identité, connaissances et esprit autonome. Communication bidirectionnelle, apprentissage à partir des retours. Utilisez
organization_spawn.
Si la tâche est du code → swarm. Si la tâche est une expertise métier → organization.
Quand lancer des agents
- Tâches de codage indépendantes — fonctionnalités, corrections de bugs, refactorisations qui peuvent être décrites comme des affectations autonomes avec des critères d'acceptation clairs
- Travail parallèle — plusieurs tâches qui ne dépendent pas les unes des autres
- Tâches que l'utilisateur souhaite déléguer — « avoir un agent travaillant sur X »
Quand NE PAS lancer
- Les tâches que vous pouvez faire directement avec vos outils en < 5 étapes
- Les tâches nécessitant une interaction utilisateur en temps réel ou un accès au navigateur
- Les tâches qui dépendent de la sortie d'un autre agent (attendez que le premier se termine)
- Le travail de domaine non-codage (marketing, recherche, design) — utilisez organization à la place
Rédiger de bonnes descriptions de tâches
La description de la tâche est l'entrée la plus importante. Une bonne tâche :
- Énonce clairement le quoi : « Ajouter la pagination au endpoint /api/users »
- Inclut les critères d'acceptation : « Doit passer les tests existants, ajouter un nouveau test pour le paramètre page_size »
- Référence les fichiers spécifiques quand possible : « Modifier src/routes/users.ts et src/tests/users.test.ts »
- Mentionne les contraintes : « Ne pas modifier le schéma de base de données »
Mauvais : « Corriger l'API » Bon : « Corriger l'erreur 500 sur GET /api/users quand page > total_pages. Retourner un tableau vide à la place. Ajouter un cas de test. »
Sélection du profil
- Laisser EloPhanto auto-sélectionner sauf si vous avez une forte préférence
- L'auto-sélection utilise la correspondance par mots-clés contre les
strengthsdu profil - Remplacez avec le paramètre
profilequand vous savez quel agent est le meilleur
Stratégie de surveillance
- Utilisez
swarm_statuspour vérifier les agents périodiquement - Le moniteur en arrière-plan gère les vérifications de routine (tmux actif, PR créée, statut CI)
- Vérifiez manuellement quand l'utilisateur demande « comment vont mes agents ? »
Redirection
- Utilisez
swarm_redirecttôt — ne tardez pas pour corriger une déviation majeure - Soyez spécifique : « Utiliser le type ConfigSnapshot existant de src/types/config.ts »
- Ne redirigez pas pour les préférences de style — gardez cela pour la revue de code
Anti-motifs
- Trop d'agents à la fois — respecter max_concurrent_agents, chacun nécessite ~3GB de RAM
- Tâches vagues — « améliorer la base de code » gaspillera du temps et des tokens
- Micro-gestion — ne redirigez pas toutes les 2 minutes, laissez les agents travailler
- Ignorer les défaillances — si un agent échoue, lisez la raison avant de le relancer
- Ignorer la revue — toujours revérifier les PRs avant de les fusionner, même si CI passe
Vérifier
- L'autre agent / outil / canal destinataire a effectivement reçu le message ; un accusé de réception, un ID de message ou une charge utile de réponse est capturé
- L'identité, les scopes et les permissions utilisés par l'appel étaient le minimum requis ; les tokens surprivilégiés sont signalés
- La gestion des défaillances a été exercée : au moins un chemin de retry/timeout/permission-denied est montré comme fonctionnant correctement
- Le contexte de remise passé à l'acteur suivant est suffisamment complet pour que le destinataire puisse agir sans question de suivi
- Tout état muté (config, mémoire, queue, fichier) est listé avec des valeurs avant/après, pas seulement « mise à jour »
- Le matériel sensible (clés, tokens, PII) a été masqué des journaux/transcriptions partagées dans les preuves de vérification