Claude DevFleet Multi-Agent Orchestration

Sélectionné par Skill Harbor : un workflow complet d'orchestration multi-agents au-dessus du serveur Claude DevFleet. Le flux est Planifier, Lancer, Suivre, Rapporter. plan_project transforme une description en langage clair en projet avec DAG de missions, chaînées par depends_on avec auto_dispatch activé ; vous montrez le plan, obtenez l'approbation, puis lancez la mission racine pendant que les autres démarrent automatiquement à la complétion des dépendances. Chaque agent tourne dans un worktree git isolé avec outillage complet et fusionne automatiquement à la fin. Les outils couvrent tout le cycle de vie : create_project, create_mission, dispatch_mission, cancel_mission, wait_for_mission (bloque jusqu'au timeout, préférez sonder get_mission_status toutes les 30 à 60 secondes pour les longs runs), get_report (fichiers modifiés, ce qui a été fait, erreurs, prochaines étapes), get_dashboard (agents en cours, stats, activité), list_projects, list_missions. La concurrence monte à 3 agents par défaut via DEVFLEET_MAX_AGENTS, le watcher de missions mettant le reste en file. Les règles sont fermes : toujours confirmer le plan avec l'utilisateur avant de lancer sauf s'il a dit d'y aller, lire le rapport d'une mission échouée avant de réessayer, ne jamais créer de dépendances circulaires, et les conflits de fusion restent sur la branche du worktree de l'agent pour résolution manuelle. Par @affaan-m, listé ici avec crédit à son créateur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : le serveur DevFleet est un projet séparé (github.com/LEC-AI/claude-devfleet) que vous installez et lancez vous-même, puis connectez via MCP à localhost:18801 ; vérifiez que le processus sur ce port est bien le binaire DevFleet que vous avez installé avant de connecter. Chaque agent est une session complète, donc les coûts en jetons se multiplient ; sondez plutôt que d'attendre en blocage sur les longues missions. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.