Protocoles de Communication d'Équipe

Protocoles pour une communication efficace entre agents coéquipiers, incluant la sélection des types de messages, les workflows d'approbation de plan, les procédures d'arrêt et les anti-modèles courants à éviter.

Quand Utiliser Cette Compétence

• Établir les normes de communication pour une nouvelle équipe
• Choisir entre les types de messages (message, broadcast, shutdown_request)
• Gérer les workflows d'approbation de plan
• Gérer l'arrêt gracieux d'une équipe
• Découvrir les identités et capacités des coéquipiers

Sélection des Types de Messages

message (Message Direct) — Choix Par Défaut

Envoyer à un coéquipier spécifique unique :

{
  "type": "message",
  "recipient": "implementer-1",
  "content": "Your API endpoint is ready. You can now build the frontend form.",
  "summary": "API endpoint ready for frontend"
}

Utiliser pour : Mises à jour de tâches, coordination, questions, notifications d'intégration.

broadcast — Utiliser Avec Parcimonie

Envoyer à TOUS les coéquipiers simultanément :

{
  "type": "broadcast",
  "content": "Critical: shared types file has been updated. Pull latest before continuing.",
  "summary": "Shared types updated"
}

Utiliser UNIQUEMENT pour : Blocages critiques affectant tout le monde, changements majeurs aux ressources partagées.

Pourquoi avec parcimonie ? : Chaque broadcast envoie N messages distincts (un par coéquipier), consommant des ressources API proportionnelles à la taille de l'équipe.

shutdown_request — Terminaison Gracieuse

Demander à un coéquipier de s'arrêter :

{
  "type": "shutdown_request",
  "recipient": "reviewer-1",
  "content": "Review complete, shutting down team."
}

Le coéquipier répond avec shutdown_response (approuver ou rejeter avec raison).

Anti-Modèles de Communication

Workflow d'Approbation de Plan

Quand un coéquipier est déployé avec plan_mode_required :

1. Le coéquipier crée un plan en utilisant les outils d'exploration en lecture seule
2. Le coéquipier appelle ExitPlanMode qui envoie une plan_approval_request au lead
3. Le lead examine le plan
4. Le lead répond avec plan_approval_response :

Approuver :

{
  "type": "plan_approval_response",
  "request_id": "abc-123",
  "recipient": "implementer-1",
  "approve": true
}

Rejeter avec feedback :

{
  "type": "plan_approval_response",
  "request_id": "abc-123",
  "recipient": "implementer-1",
  "approve": false,
  "content": "Please add error handling for the API calls"
}

Protocole d'Arrêt

Séquence d'Arrêt Gracieux

1. Le lead envoie shutdown_request à chaque coéquipier
2. Le coéquipier reçoit la demande comme un message JSON avec type: "shutdown_request"
3. Le coéquipier répond avec shutdown_response :
   • approve: true — Le coéquipier sauvegarde l'état et quitte
   • approve: false + raison — Le coéquipier continue de travailler
4. Le lead gère les rejets — Attendre que le coéquipier finisse, puis recommencer
5. Après l'arrêt de tous les coéquipiers — Appeler TeamDelete pour supprimer les ressources d'équipe

Gérer les Rejets

Si un coéquipier rejette l'arrêt :

• Vérifier leur raison (généralement « encore en train de travailler sur la tâche »)
• Attendre la fin de leur tâche actuelle
• Recommencer la demande d'arrêt
• Si urgent, l'utilisateur peut forcer l'arrêt

Découverte de Coéquipiers

Trouver les membres de l'équipe en lisant le fichier de config :

Localisation : ~/.claude/teams/{team-name}/config.json

Structure :

{
  "members": [
    {
      "name": "security-reviewer",
      "agentId": "uuid-here",
      "agentType": "team-reviewer"
    },
    {
      "name": "perf-reviewer",
      "agentId": "uuid-here",
      "agentType": "team-reviewer"
    }
  ]
}

Toujours utiliser name pour la messagerie et l'assignation de tâches. Ne jamais utiliser agentId directement.

Dépannage

Un coéquipier ne répond pas aux messages. Vérifier le statut de tâche du coéquipier. S'il est inactif, il a peut-être terminé sa tâche et attend qu'on lui assigne un nouveau travail ou qu'on l'arrête. S'il est encore actif, il est peut-être en cours d'exécution et traitera les messages une fois l'opération actuelle terminée.

Le lead envoie des broadcasts pour chaque mise à jour de statut. C'est un anti-modèle courant. Les broadcasts sont coûteux — chacun envoie N messages. Utiliser des messages directs (type: "message") pour les mises à jour point à point. Réserver les broadcasts pour les changements critiques de ressources partagées comme un contrat d'interface mis à jour.

Un coéquipier a rejeté une demande d'arrêt de manière inattendue. Le coéquipier est encore en train de travailler. Vérifier la raison du rejet dans le champ content de shutdown_response, attendre la fin du travail, puis recommencer. Ne jamais forcer l'arrêt d'un coéquipier qui a du travail non sauvegardé.

Une plan_approval_request est arrivée mais le request_id est manquant. Le coéquipier a appelé ExitPlanMode sans le contexte de demande requis. Faire au coéquipier de revenir en mode plan, terminer l'exploration, et appeler ExitPlanMode à nouveau. Le request_id est généré automatiquement par le système de mode plan.

Deux coéquipiers attendent l'un l'autre et aucun ne fait de progrès. C'est un blocage : les deux sont bloqués en attente que l'autre finisse en premier. Le lead doit envoyer un message direct à un coéquipier avec un stub ou un résultat partiel pour qu'il puisse se débloquer et continuer.

Compétences Connexes

• team-composition-patterns — Sélectionner les types d'agents et la taille de l'équipe avant d'établir les normes de communication
• parallel-feature-development — Utiliser les protocoles de communication pour coordonner les handoffs d'intégration entre les implémenteurs parallèles