team

Compétence Team

Génère N agents coordonnés travaillant sur une liste de tâches partagée à l'aide de l'équipe d'agents implicite de Claude Code. Claude Code 2.1.178+ a supprimé les appels natifs TeamCreate/TeamDelete ; avec CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, chaque session dispose d'une équipe implicite et les coéquipiers sont générés directement avec l'outil Agent/Tâche en utilisant des valeurs name distinctes. Cette compétence préserve toujours l'orchestration héritée de workers tmux/CLI d'OMC là où elle est documentée (omc team / /omc-teams).

L'alias de compatibilité swarm a été supprimé dans la version #1131.

Utilisation

/oh-my-claudecode:team N:agent-type "description de la tâche"
/oh-my-claudecode:team "description de la tâche"
/oh-my-claudecode:team ralph "description de la tâche"

Paramètres

• N - Nombre d'agents coéquipiers (1-20). Optionnel ; par défaut, le dimensionnement est automatique en fonction de la décomposition de la tâche.
• agent-type - Agent OMC à générer pour l'étape team-exec (par exemple, executor, debugger, designer, codex, gemini, antigravity). Optionnel ; par défaut, le routage est basé sur l'étape. Utilisez codex pour générer des workers Codex CLI, gemini pour des workers Gemini CLI (niveau entreprise/clé API), ou antigravity pour des workers Antigravity CLI (agy) (successeur de Google de la CLI Gemini ; nécessite l'installation des CLI respectives). Voir Routage des Agents par Étape ci-dessous.
• task - Tâche de haut niveau à décomposer et à distribuer entre les coéquipiers.
• ralph - Modificateur optionnel. Lorsqu'il est présent, il enveloppe le pipeline de l'équipe dans la boucle de persistance de Ralph (nouvelle tentative en cas d'échec, vérification par l'architecte avant l'achèvement). Voir Composition Équipe + Ralph ci-dessous.

Exemples

/team 5:executor "corriger toutes les erreurs TypeScript dans le projet"
/team 3:debugger "corriger les erreurs de construction dans src/"
/team 4:designer "implémenter des mises en page responsives pour tous les composants de page"
/team "refactoriser le module d'authentification avec une revue de sécurité"
/team ralph "construire une API REST complète pour la gestion des utilisateurs"
# Avec des workers Codex CLI (nécessite : npm install -g @openai/codex)
/team 2:codex "examiner l'architecture et suggérer des améliorations"
# Avec des workers Gemini CLI (nécessite : npm install -g @google/gemini-cli)
/team 2:gemini "reconcevoir les composants de l'interface utilisateur"
# Avec des workers Antigravity CLI (nécessite : installer selon https://antigravity.google)
/team 2:antigravity "reconcevoir les composants de l'interface utilisateur"
# Mixte : Codex pour l'analyse backend, Gemini/Antigravity pour le frontend (délégation par tâche avec /oh-my-claudecode:ask)

Architecture

Utilisateur : "/team 3:executor corriger toutes les erreurs TypeScript"
              |
              v
      [ORCHESTRATEUR D'ÉQUIPE (Chef)]
              |
              +-- Utiliser l'équipe Claude Code implicite de la session
              |       -> pas d'appel TeamCreate ; le chef reste la session actuelle
              |
              +-- Analyser et décomposer la tâche en sous-tâches
              |       -> explorer/architecte produit une liste de sous-tâches
              |
              +-- Créer des entrées de liste de tâches à partir du plan d'implémentation
              |       -> Entrées TODO/tâches #1, #2, #3 avec dépendances
              |
              +-- Mettre à jour les entrées de liste de tâches (pré-assigner les propriétaires)
              |       -> tâche #1 propriétaire=worker-1, etc.
              |
              +-- Tâche(name="worker-1") x 3
              |       -> génère les coéquipiers dans l'équipe
              |
              +-- Boucle de surveillance
              |       <- messages des coéquipiers (livrés automatiquement par la surface d'équipe active)
              |       -> revue liste-tâches/TodoWrite pour la progression
              |       -> envoyer des messages aux coéquipiers via la surface d'équipe active pour débloquer/coordonner
              |
              +-- Achèvement
                      -> demander l'arrêt à chaque coéquipier via la surface d'équipe active
                      <- accusé de réception d'arrêt des coéquipiers
                      -> effacer l'état de l'équipe OMC (pas d'appel TeamDelete)
                      -> rm .omc/state/team-state.json

Modèle natif d'équipe Claude Code (2.1.178+) :

- Aucun répertoire ~/.claude/teams/<nom>/ n'est créé par cette compétence.
- Aucun appel TeamCreate/TeamDelete n'est disponible.
- `team_name` est accepté par Claude Code natif uniquement comme métadonnée héritée ignorée ; ne vous fiez pas à cela pour le routage.
- Générez les coéquipiers directement via Agent/Tâche avec `name="worker-N"`.

Relation avec le Workflow d'Objectif

L'équipe est l'autorité OMC pour l'exécution parallèle et par étapes. Utilisez les politiques de conflit déterministes refuse, adopt_existing, et artifact_only plutôt que la gestion d'avertissement non déterministe. Si une tâche mentionne Claude Code /goal, Ralph, ou Ultragoal basé sur les artefacts uniquement, gardez l'Équipe comme autorité de boucle principale à moins que le chef ne délègue explicitement. Utilisez /goal uniquement comme cible documentée de transfert natif de Claude Code ou comme preuve visible de la session principale ; ne prétendez pas que l'évaluateur /goal exécute indépendamment des commandes, lit des fichiers ou remplace team-verify / team-fix. Les références Ultragoal basées sur les artefacts uniquement doivent être traitées comme des artefacts durables de registre d'objectifs/de points de contrôle/de preuves, et non comme une exécution de worker en elles-mêmes.

Pipeline par Étapes (Runtime d'Équipe Canonique)

L'exécution de l'équipe suit un pipeline par étapes :

team-plan -> team-prd -> team-exec -> team-verify -> team-fix (boucle)

Routage des Agents par Étape

Chaque étape du pipeline utilise des agents spécialisés – pas seulement des exécuteurs. Le chef sélectionne les agents en fonction de l'étape et des caractéristiques de la tâche.

Étape	Agents Requis	Agents Optionnels	Critères de Sélection
team-plan	explore (haiku), planner (opus)	analyst (opus), architect (opus)	Utilisez analyst pour des exigences floues. Utilisez architect pour des systèmes avec des limites complexes.
team-prd	analyst (opus)	critic (opus)	Utilisez critic pour remettre en question le périmètre.
team-exec	executor (sonnet)	executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet)	Associez l'agent au type de sous-tâche. Utilisez executor (modèle=opus) pour un travail autonome complexe, designer pour l'interface utilisateur, debugger pour les problèmes de compilation, writer pour la documentation, test-engineer pour la création de tests.
team-verify	verifier (sonnet)	test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus)	Exécutez toujours verifier. Ajoutez security-reviewer pour les modifications d'authentification/chiffrement. Ajoutez code-reviewer pour plus de 20 fichiers ou des modifications architecturales. code-reviewer couvre également les vérifications de style/formatage.
team-fix	executor (sonnet)	debugger (sonnet), executor (opus)	Utilisez debugger pour les erreurs de type/construction et l'isolation des régressions. Utilisez executor (modèle=opus) pour des corrections complexes multi-fichiers.

Règles de routage :

1. Le chef choisit les agents par étape, pas l'utilisateur. Le paramètre N:agent-type de l'utilisateur ne remplace que le type de worker de l'étape team-exec. Toutes les autres étapes utilisent des spécialistes appropriés à l'étape.
2. Les agents spécialistes complètent les agents exécuteurs. Acheminez l'analyse/la revue vers les agents architecte/critique Claude et le travail d'interface utilisateur vers les agents designer. Les workers Tmux CLI sont à usage unique et ne participent pas à la communication d'équipe.
3. Le mode de coût affecte le niveau de modèle. En déclassement : agents opus vers sonnet, sonnet vers haiku là où la qualité le permet. team-verify utilise toujours au moins sonnet.
4. Le niveau de risque escalade la revue. Les modifications sensibles à la sécurité ou de plus de 20 fichiers doivent inclure security-reviewer + code-reviewer (opus) dans team-verify.

Critères d'Entrée/Sortie des Étapes

• team-plan
  • Entrée : L'invocation de l'équipe est analysée et l'orchestration commence.
  • Agents : explore scanne le codebase, planner crée le graphe de tâches, éventuellement analyst/architect pour les tâches complexes.
  • Sortie : La décomposition est terminée et un graphe de tâches exécutable est préparé.
• team-prd
  • Entrée : Le périmètre est ambigu ou les critères d'acceptation sont manquants.
  • Agents : analyst extrait les exigences, éventuellement critic.
  • Sortie : Les critères d'acceptation et les limites sont explicites.
• team-exec
  • Entrée : L'attribution de la liste de tâches et la génération des workers sont terminées.
  • Agents : Workers générés comme le type spécialisé approprié pour chaque sous-tâche (voir le tableau de routage).
  • Sortie : Les tâches d'exécution atteignent un état terminal pour le passage en cours.
• team-verify
  • Entrée : Le passage d'exécution se termine.
  • Agents : verifier + réviseurs appropriés à la tâche (voir le tableau de routage).
  • Sortie (réussite) : Les barrières de vérification sont franchies sans suivi requis.
  • Sortie (échec) : Des tâches de correction sont générées et le contrôle passe à team-fix.
• team-fix
  • Entrée : La vérification a trouvé des défauts/régressions/critères incomplets.
  • Agents : executor/debugger selon le type de défaut.
  • Sortie : Les corrections sont terminées et le flux retourne à team-exec puis team-verify.

Boucle Vérifier/Corriger et Conditions d'Arrêt

Continuez team-exec -> team-verify -> team-fix jusqu'à ce que :

1. la vérification réussisse et qu'aucune tâche de correction requise ne reste, ou
2. le travail atteigne un résultat bloqué/échoué terminal explicite avec des preuves.

team-fix est limité par un nombre maximal de tentatives. Si les tentatives de correction dépassent la limite configurée, transition vers l'état terminal failed (pas de boucle infinie).

Convention de Transfert entre Étapes

Lors de la transition entre les étapes, le contexte important — décisions prises, alternatives rejetées, risques identifiés — ne réside que dans l'historique de la conversation du chef. Si le contexte du chef se compacte ou si les agents redémarrent, cette connaissance est perdue.

Chaque étape terminée DOIT produire un document de transfert avant la transition.

Le chef écrit les transferts dans .omc/handoffs/<nom-étape>.md.

Format du Transfert

## Transfert : <étape-courante> → <étape-suivante>

- **Décidé** : [décisions clés prises dans cette étape]
- **Rejeté** : [alternatives considérées et pourquoi elles ont été rejetées]
- **Risques** : [risques identifiés pour l'étape suivante]
- **Fichiers** : [fichiers clés créés ou modifiés]
- **Restant** : [éléments à traiter par l'étape suivante]

Règles de Transfert

1. Le chef lit le transfert précédent AVANT de générer les agents de l'étape suivante. Le contenu du transfert est inclus dans les invites de génération des agents de l'étape suivante, garantissant que les agents commencent avec un contexte complet.
2. Les transferts s'accumulent. L'étape de vérification peut lire tous les transferts antérieurs (plan → prd → exec) pour un historique décisionnel complet.
3. En cas d'annulation de l'équipe, les transferts survivent dans .omc/handoffs/ pour une reprise de session. Ils ne sont pas supprimés par le nettoyage natif de l'équipe Claude Code ; aucun appel TeamDelete n'existe dans Claude Code 2.1.178+.
4. Les transferts sont légers. 10-20 lignes maximum. Ils capturent les décisions et les justifications, pas les spécifications complètes (celles-ci vivent dans des fichiers livrables comme DESIGN.md).

Exemple

## Transfert : team-plan → team-exec

- **Décidé** : Architecture microservices avec 3 services (auth, api, worker). PostgreSQL pour la persistance. JWT pour les jetons d'authentification.
- **Rejeté** : Monolithe (problèmes de mise à l'échelle), MongoDB (l'expertise de l'équipe est SQL), cookies de session (conception API-first).
- **Risques** : Le service worker a besoin de Redis pour la file d'attente de travaux — pas encore provisionné. Le service d'authentification n'a pas de limitation de débit dans la conception initiale.
- **Fichiers** : DESIGN.md, TEST_STRATEGY.md
- **Restant** : Scripts de migration de base de données, configuration du pipeline CI/CD, provisionnement Redis.

Sémantique de Reprise et d'Annulation

• Reprendre : redémarrez à partir de la dernière étape non terminale en utilisant l'état des étapes + l'état en direct des tâches. Lisez .omc/handoffs/ pour récupérer le contexte de transition d'étape.
• Annuler : /oh-my-claudecode:cancel demande l'arrêt des coéquipiers, attend les réponses (au mieux), marque la phase cancelled avec active=false, capture les métadonnées d'annulation, puis supprime les ressources de l'équipe et efface/préserve l'état de l'équipe conformément à la politique. Les fichiers de transfert dans .omc/handoffs/ sont conservés pour une éventuelle reprise.
• Les états terminaux sont complete, failed et cancelled.

Porte de compatibilité psmux tmux pour Windows

Sur Windows natif, ne dites pas aux utilisateurs que /team nécessite WSL ou que tmux est indisponible jusqu'à ce que le binaire compatible tmux réel ait été vérifié. psmux natif installe une commande compatible tmux (souvent tmux / tmux.cmd) et est un multiplexeur d'équipe pris en charge.

Avant de bloquer ou de recourir à une solution de repli sur Windows :

1. Vérifiez tmux -V (ou l'équivalent de la plateforme tel que where tmux suivi de tmux -V).
2. Considérez un tmux -V réussi basé sur psmux comme tmux disponible.
3. Si psmux/tmux est disponible, continuez le flux normal de l'Équipe ; n'émettez pas de conseils de type « WSL requis ».
4. Seulement lorsqu'aucun binaire compatible tmux n'est disponible, dites à l'utilisateur d'installer psmux pour la prise en charge Windows native ou d'utiliser WSL2 comme alternative.

Workflow

Phase 1 : Analyser l'Entrée

• Extraire N (nombre d'agents), valider 1-20
• Extraire agent-type, valider qu'il correspond à un sous-agent OMC connu
• Extraire la description de la tâche

Phase 2 : Analyser et Décomposer

Utilisez explore ou architect (via MCP ou agent) pour analyser le codebase et diviser la tâche en N sous-tâches :

• Chaque sous-tâche doit être limitée à un fichier ou à un module pour éviter les conflits
• Les sous-tâches doivent être indépendantes ou avoir un ordre de dépendance clair
• Chaque sous-tâche n

…

[suite tronquée pour la traduction]