agmsg team

Développement piloté par le modèle sélectionné (agmsg team)

Utilisez cette compétence pour former une équipe de pairs limitée à la tâche en cours. Il n'y a pas de commandant permanent ni de pool de workers résidents : le Propriétaire de la Tâche est le modèle que vous avez sélectionné pour cette session (dans Claude Code ou Codex). Il possède la tâche de bout en bout, puis démarre uniquement les rôles pairs nécessaires pour des travaux limités via agmsg.

Nécessite la compétence agmsg (https://github.com/fujibee/agmsg) installée, et les CLI claude et codex disponibles — une équipe agmsg crée des pairs sur les deux. Lisez la compétence agmsg installée avant d'appeler ses scripts. Utilisez uniquement ses scripts Bash fournis ; n'accédez jamais directement à sa base de données, ses fichiers d'équipe ou sa configuration.

Démarrer ou reprendre une équipe

Résolvez l'équipe avant d'effectuer le travail de la tâche. Utilisez le nom CLI de la session en cours (claude-code ou codex) partout où <cli> apparaît ci-dessous.

1. Si l'invocation spécifie un nom d'équipe, utilisez ce nom exact. S'il est absent localement, créez/rejoignez-la avec join.sh ; si elle existe, inspectez son effectif avec team.sh et travaillez dedans. Ne créez pas d'homonyme local lorsque la demande est de tirer une équipe distante — suivez le flux de tirage distant d'agmsg à la place.
2. Sans nom explicite, exécutez whoami.sh "$(pwd)" <cli> et team-list.sh --scope project "$(pwd)". Reprenez la seule équipe associée à ce projet. S'il n'y en a pas, créez une équipe locale nommée à partir d'un slug sûr en minuscules du nom du répertoire du projet (par exemple, payments-api). Si plusieurs équipes s'appliquent, demandez à l'utilisateur quelle équipe existante utiliser ; ne choisissez jamais arbitrairement.
3. Enregistrez le Propriétaire de la Tâche avec join.sh <team> <agent> <cli> "$(pwd)" si nécessaire. Choisissez une identité non utilisée telle que <team>-owner (éventuellement qualifiée par le modèle, par exemple <team>-sol-owner) ; inspectez d'abord team.sh <team> et suffixez un numéro en cas de collision. Souvenez-vous de l'équipe résolue et de l'identité de l'agent pour cette tâche.
4. Vérifiez la boîte de réception du propriétaire au début de chaque tour repris et avant de déclarer la tâche terminée : inbox.sh <team> <owner>.

La première invocation crée donc l'équipe de projet par défaut lorsqu'aucune équipe de projet utilisable n'existe ; une équipe fournie explicitement l'emporte toujours. Les équipes et les identités des agents sont des états locaux d'agmsg, donc ne supposez pas qu'elles sont partagées entre machines à moins qu'une synchronisation distante ait été configurée.

Routage des modèles

Le Propriétaire de la Tâche (TO) contrôle la sélection du modèle et l'escalade. Les workers retournent leurs résultats ou demandes d'escalade au TO ; ils ne réaffectent jamais le travail ni ne le transmettent directement. Les frontières entre fournisseurs n'ont pas d'importance car le contexte et les résultats de la tâche peuvent circuler via agmsg.

Utilisez le modèle le moins cher capable de réaliser la tâche de manière fiable. Le rôle définit la responsabilité ; le modèle définit la capacité de raisonnement nécessaire pour le ticket en cours. Ne choisissez pas un modèle coûteux simplement parce qu'un rôle s'appelle Consultant ou Spécialiste.

• Général — Luna : implémentation courante, modifications mécaniques, refactoring simple, documentation simple, et autres travaux clairement exécutifs.
• Consultant — Terra ou Sonnet : planification, analyse des besoins/produit, revues, conception ou architecture simple, débogage modéré, et analyse de compromis. Choisissez selon l'adéquation à la tâche, pas par affinité avec un fournisseur.
• Spécialiste — Sol ou Opus : architecture ou UX complexe, débogage difficile et conception de refactoring, revue approfondie, raisonnement inter-domaines, et décisions ayant un impact aval substantiel. Aucun des deux n'est le défaut obligatoire pour le rôle.
• Escalade — Astra : raisonnement exceptionnellement difficile ou à haut risque, problèmes système non résolus, ou revue indépendante finale après que Sol ou Opus reste insuffisant. Astra n'est pas un modèle Spécialiste par défaut.

La route normale est Luna → Terra/Sonnet → Sol/Opus → Astra ; le TO peut sauter un niveau lorsque le ticket le justifie clairement. Escaladez en fonction de l'ambiguïté, de la profondeur de raisonnement requise, de la taille du contexte, du coût d'échec, des tentatives infructueuses antérieures, ou de la confiance insuffisante — pas de l'importance seule de la tâche.

Lorsqu'un worker estime que le modèle qui lui est assigné est insuffisant, il rapporte ce qui est établi, ce qui reste non résolu, pourquoi l'approche actuelle est insuffisante, si une escalade est recommandée, et quel raisonnement supplémentaire est nécessaire. Le TO décide alors de réessayer, de changer au sein du même niveau, d'escalader, ou de demander un avis indépendant.

L'utilisateur sélectionne le modèle Propriétaire avant d'invoquer cette compétence ; la compétence ne change pas le modèle d'une session en cours. Si le modèle choisi n'est pas clair, demandez à l'utilisateur plutôt que de créer un second Propriétaire pour décider.

Le Propriétaire de la Tâche sélectionné doit établir les exigences et les critères d'acceptation, inspecter le code et la documentation pertinents, diviser uniquement le travail indépendant, implémenter ou intégrer le résultat, exécuter les tests appropriés, et vérifier la complétion. Luna est le modèle de worker délégué par défaut sauf si les règles de routage justifient une escalade.

Déléguez librement la recherche en lecture seule, l'assurance qualité et la revue de sécurité lorsqu'elles sont indépendantes. Ne faites pas éditer le même fichier simultanément par deux pairs ; partitionnez les fichiers ou utilisez des espaces de travail Git séparés. Un Propriétaire de Tâche est responsable des résultats, pas d'effectuer personnellement chaque étape.

Utilisez un message en forme de ticket. Envoyez uniquement le contexte dont le destinataire a besoin, et citez les fichiers, les commits, les diffs ou les résultats antérieurs au lieu de faire redécouvrir ces éléments par un autre modèle. Lisez modèles de message lors de la délégation ou de l'escalade.

Rôles et communication directe

• Propriétaire de la Tâche (votre modèle sélectionné) : possède le périmètre, les décisions, l'intégration, les tests et les vérifications finales.
• Ingénieur / Enquêteur : reçoit un ticket d'implémentation ou de recherche limité et rapporte directement au propriétaire.
• Chef de Produit / PdM : à utiliser lorsque le problème produit ou les besoins nécessitent une définition avant la conception ou l'implémentation. Clarifiez le résultat utilisateur, le périmètre, la priorité, les règles métier et les critères d'acceptation ; ne choisissez pas la structure d'écran, le copy UI ou l'implémentation, et remontez les décisions produit non résolues au propriétaire.
• Designer Produit : à utiliser lorsque les besoins produit nécessitent une spécification d'écran/UX avant l'implémentation. Définissez la hiérarchie de l'information, les flux, les états non heureux et un copy UI concis et cohérent à un niveau prêt pour l'ingénieur ; ne modifiez pas les exigences, les règles métier, l'API/le modèle de données ou l'approche d'implémentation, et signalez les lacunes ou contradictions dans les exigences au propriétaire.
• Relecteur d'accessibilité : à utiliser pour les modifications significatives de l'interface utilisateur ou des flux utilisateur lorsque une revue d'accessibilité est nécessaire. Vérifiez le fonctionnement au clavier, le focus, les étiquettes, le retour d'erreur et de statut, le contraste, et les instructions qui reposent uniquement sur la couleur ; signalez les obstacles avec des preuves et une correction pratique, et normalement ne modifiez pas le code ou les exigences.
• QA : à utiliser pour les changements de comportement, les corrections de bugs, les modifications multi-fichiers, les risques de régression, les critères d'acceptation multiples, ou les angles morts significatifs du propriétaire. Le QA rapporte normalement ses conclusions et ne modifie pas le code.
• Relecteur de sécurité : à utiliser uniquement pour l'auth/authz, les sessions/cookies, les API/entrées externes, les uploads, les secrets, la base de données/RLS, l'infrastructure, les mises à jour de dépendances, ou les données sensibles. Signalez la sévérité, les preuves et la correction ; ne modifiez pas normalement le code.
• Consultant : donne uniquement un jugement ciblé. Le propriétaire fournit le Problème, l'État actuel, les Options, les Compromis, la Recommandation, les fichiers pertinents et une Question exacte. Ne l'envoyez pas pour réexaminer l'ensemble du dépôt.
• Spécialiste : traite un problème difficile étroitement défini après routage par difficulté, incertitude, coût d'échec et tentatives antérieures. Ne sélectionnez pas un modèle uniquement à partir de ce titre de rôle.

Chaque worker retourne son résultat au TO. Les workers peuvent communiquer directement si nécessaire, mais ils ne doivent pas réaffecter le travail ni choisir le rôle/modèle suivant ; le TO reste l'autorité de routage et d'alignement.

Escalade et création de workers

Conservez le Propriétaire sélectionné tout au long de la tâche. Escaladez uniquement à un point de décision ou d'échec concret ; enregistrez la réponse à ce Propriétaire, qui prend la décision d'implémentation et de finition.

Cycle de vie à la demande et réutilisation du contexte

Traitez tout rôle non propriétaire comme un worker à la demande : spawn-ez-le pour un ticket limité, attendez son rapport, incorporez le résultat, puis despawn-ez-le. Ne conservez pas de processus QA, de sécurité, consultant ou ingénieur inactifs entre les éléments de travail.

spawn.sh <type> <name> --project "$(pwd)" [--team <team>] [--model <cli-model-id>] [--boot-prompt "<ticket>"] [--no-wait] [--fresh] pré-enregistre <name>, ouvre un volet tmux (dans tmux) ou un nouveau terminal, et démarre le CLI. Un spawn claude-code bloque jusqu'à ce que son watcher s'attache ; un spawn codex revient immédiatement, donc un pair codex doit recevoir son affectation via --boot-prompt, pas un message envoyé après qu'il soit inactif.

Pour ramener un rôle plus tard dans la même tâche, spawn-ez le même nom sans --fresh — agmsg reprend sa session enregistrée, donc envoyez uniquement le delta (statut, fichiers/commit pertinents, une prochaine question). Utilisez --fresh uniquement lorsque le contexte antérieur serait trompeur.

despawn.sh <team> <owner> <name> [--force] est l'inverse de spawn et ne démantèle qu'un rôle que ce propriétaire a créé. Un despawn gracieux d'un pair codex rapporte souvent "no live lock" (codex n'a pas de watcher) — c'est normal ; ajoutez --force uniquement si une fenêtre de terminal reste ouverte. Ne désactivez jamais un pair démarré manuellement.

Interfaces agmsg

Résolvez le répertoire scripts/ de la compétence agmsg depuis l'endroit où elle est installée dans l'environnement actuel (son répertoire de compétence) plutôt que de supposer un chemin fixe, puis appelez :

bash <agmsg-skill-dir>/scripts/send.sh <team> <from> <to> "<structured ticket>"
bash <agmsg-skill-dir>/scripts/inbox.sh <team> <agent>
bash <agmsg-skill-dir>/scripts/team.sh <team>
bash <agmsg-skill-dir>/scripts/spawn.sh <codex|claude-code> <agent> --project "$(pwd)" --team <team> --model <installed-cli-model-id> --boot-prompt "<bounded ticket>"
bash <agmsg-skill-dir>/scripts/despawn.sh <team> <owner> <spawned-agent> [--force]

--model est transmis par agmsg au CLI installé. Utilisez uniquement des ID de modèle locaux vérifiés — pour les pairs Codex gpt-5.6-luna, gpt-5.6-terra, gpt-5.6-sol, gpt-6-astra ; pour un autre CLI, utilisez son identifiant documenté plutôt que d'en inventer un. Un pair Codex sans distribution par moniteur doit recevoir son affectation initiale via --boot-prompt, pas un message envoyé après qu'il soit inactif.

Créez un worker uniquement lorsque cela crée un travail parallèle utile. Préférez un worker au périmètre étroit plutôt que plusieurs workers spéculatifs ; parallélisez uniquement des tickets indépendants. Pour un pair démarré manuellement, send.sh suffit. Inspectez l'effectif avant d'assigner ; chaque from et to doit être enregistré sauf si vous utilisez intentionnellement l'exception --force documentée d'agmsg.

Portail de complétion

Le Propriétaire de la Tâche sélectionné ne ferme la tâche qu'après que les exigences et les critères d'acceptation sont satisfaits, les tests pertinents passent, les revues QA et de sécurité déclenchées sont résolues, aucun bloqueur ne subsiste, et le diff ne contient aucune modification non liée. Si une recommandation de modèle coûteux a été utilisée, validez et implémentez son résultat avant la fermeture.