Exécuter la squad

Appeler le coordinateur#

Adressez vos demandes dans la conversation de l'agent Squad correspondant, et non dans le terminal de votre système. Dans Copilot Harness pour VS Code, choisissez l'agent dans le sélecteur d'agents ; la CLI et l'application utilisent aussi l'agent correspondant. Consultez Bien démarrer pour l'installation et votre première conversation.

/squad request="add input validation to the login form"

Paramètres facultatifs#

• profile=default|full|security|design|accessibility|architecture|azure|modernization|compliance|operations|product — détermine l'équipe créée lors de la première exécution. Si ce paramètre est omis dans un nouveau projet, le coordinateur inspecte votre dépôt et propose un profil recommandé avant toute création.
• pack=power-platform, pack=m365-copilot ou pack=aws — ajoute au profil les rôles spécialisés d'un domaine technologique. Un pack ne remplace jamais le profil, et vous pouvez en appliquer plusieurs, séparés par des virgules. Voir Packs ci-dessous.
• tier=fast|default — une indication de niveau de modèle valable pour ce tour, qui prend le pas sur les réglages par défaut du coordinateur privilégiant le coût.
• routing=off|ranked|economy|manual — la méthode de sélection du modèle de chaque rôle, enregistrée dans team.md jusqu'à ce que vous la changiez. off (par défaut) n'applique aucune politique ; ranked choisit le modèle le mieux adapté au travail de chaque rôle parmi ceux que propose votre hôte ; economyPréversion uniquement v0.19.0-pre est ranked avec des choix moins chers pour cinq rôles d'implémentation, après votre accord ; manual vous demande de choisir, avec des suggestions préremplies. Voir Sélection du modèle par rôle ci-dessous.
• discovery=quick|standard|deep|skip — lance l'étape de découverte à la profondeur indiquée sans poser la question, ou l'ignore. Voir Étape de découverte ci-dessous.
• owner=<Member Name> — sélectionne un membre précis par son nom lorsque deux lignes de team.md partagent le même Role (par exemple owner=Beta lorsque l'équipe comporte deux lignes developer).
• mode=autonomous|autopilot — le mode d'autonomie de ce tour. Omettez-le pour travailler en mode interactif, en approuvant chaque étape.
• cost-ceiling=<positive USD>|unset — définit, remplace ou supprime explicitement le plafond de dépense estimée en modèles pour l'exécution en cours. En cas d'omission, un plafond actif n'est hérité qu'au sein de la même exécution. Voir Contrôle d'admission des coûts ci-dessous.

/squad request="threat-model the auth service" profile=security
/squad request="design the approvals app" profile=architecture pack=power-platform
/squad request="summarize the data layer" tier=fast
/squad request="reduce onboarding drop-off" discovery=standard
/squad request="build the booking service end to end" mode=autopilot cost-ceiling=20
/squad request="run security research and implement" routing=manual

Modes d'autonomie#

Ce que la squad fait avant de vous solliciter :

Autopilot est le mode « dites-le une fois, laissez-le travailler » : il orchestre l'ensemble du pipeline de manière autonome, mais s'arrête toujours pour obtenir une validation humaine avant toute action irréversible et avant la publication. Les deux points d'arrêt — action à impact et résultat final — déclenchent une notification via le canal d'approbation que vous choisissez à la création (le mode interactif vous notifie, lui, à chaque étape).

Chevauchement des transmissions en mode autopilot#

En mode=autopilot, le coordinateur lance simultanément la transmission au Scribe de l'étape N et le rôle de l'étape N+1, sous forme de deux appels dans un même bloc d'appels d'outils parallèles, lorsqu'aucune barrière ne s'applique et que trois conditions sont réunies : l'artefact propre à l'étape N est confirmé sur disque, l'outil de lancement de sous-agents de l'hôte peut être appelé plusieurs fois dans un même bloc d'appels d'outils parallèles (runSubagent de VS Code ou l'outil task de Copilot CLI, avec ou sans mode: background), et le chevauchement n'a pas été désactivé à la suite d'un échec de vérification survenu plus tôt dans cette exécution. Dans ce cas, transmettre uniquement au Scribe puis attendre constitue un défaut.

Un cost-ceiling ne désactive pas le chevauchement. Le cycle Cost Preflight qui autorise l'étape N+1 intervient entre les deux blocs parallèles et compte la dépense de l'étape N qui n'a pas encore été enregistrée comme une réservation en attente : le contrôle du plafond ne sous-estime donc jamais la dépense pendant une transmission. Une exécution interne en autopilot de fédération sans cible explicite utilise aussi ce chevauchement à la racine de sa propre sous-squad.

Le chevauchement reste désactivé dans les cas suivants :

• Mode Watch
• La squad est une racine de fédération (signalée par la présence de federation.md)
• Le cycle Cost Preflight actif est approved-over-ceiling, dont les unités de lancement restent séquentielles
• L'hôte ne dispose d'aucun outil de lancement de sous-agents acceptant plusieurs appels par bloc
• Après l'échec de vérification d'une transmission en chevauchement (exécutée parallèlement à un rôle) pendant cette exécution ; l'échec d'une transmission exécutée seule est corrigé sans désactiver le chevauchement

Lorsque le chevauchement est désactivé, le coordinateur lance la transmission au Scribe de l'étape N, attend qu'elle soit terminée et vérifiée, puis lance l'étape N+1 — exactement comme dans les versions précédentes. Lorsque le chevauchement est actif, l'étape N+1 commence pendant la transmission de l'étape N, mais l'étape N+2 ne commence qu'après le retour de cette transmission et la réussite de sa vérification.

Vérification et points de contrôle de sécurité#

Un simple Measure-SquadLedger.ps1 -Check ne suffit pas à vérifier les transmissions en chevauchement. Le coordinateur relève donc, avant le lancement, le nombre de titres du fichier d'historique cible, puis effectue la vérification avec -ExpectedHistoryCounts, en ajoutant à ce relevé les entrées que cette transmission doit créer. Le coordinateur utilise aussi -BaselinePath pour conserver une référence du contenu (longueur, SHA-256, nombre de titres) de chaque livrable écrit depuis le début de l'exécution, afin de détecter les préfixes corrompus ou modifiés lors des écritures suivantes.

Si la vérification d'une transmission en chevauchement échoue, le chevauchement est désactivé pour le reste de l'exécution. Le Scribe ne réécrit jamais l'écriture erronée ; une nouvelle entrée corrective, en ajout uniquement, est demandée, et le livrable concerné est restauré en relançant le rôle qui en est responsable (et non en modifiant l'historique). L'exécution ne franchit pas la barrière suivante avant qu'une personne ait approuvé la correction.

.copilot-tracking/squad/ et son contenu sont ignorés par Git : l'état du registre constitue donc une preuve locale, pas un élément de l'historique soumis à revue. Le code livré, les plans et les comptes rendus de revue dans plans/, research/, reviews/ et les fichiers du projet sont suivis normalement.

Banc de mesure comparative#

Un banc de mesure comparative par paires, à activer explicitement, est disponible dans tests/tier1/benchmark/Invoke-PipeliningBenchmark.ps1 (nécessite COPILOT_GITHUB_TOKEN). Les mesures en conditions réelles n'ont pas encore produit de résultat de référence ; le fonctionnement du chevauchement est donc décrit ici et dans les références du code source de la squad, sans aucune affirmation de performance.

Contrôle d'admission des coûts#

cost-ceiling est un plafond facultatif de dépense estimée en modèles pour une exécution. L'initialisation est hors plafond : le lancement du Scribe confirmé pour la configuration crée les fichiers de composition d'équipe, d'état et de tarification, et enregistre la dépense de cette configuration sans consommer de créneau soumis au plafond. Après l'initialisation, avant le premier lancement de travail et chaque cycle suivant, Cost Preflight construit un manifeste de la demande à partir des rôles prévus, des classes de lancement, des tarifs fixes des modèles, de l'orchestration, du nombre maximal de cycles conditionnels et du calibrage admissible. Il ne fournit pas de devis du coût facturé, ne plafonne pas la facture GitHub et ne régit pas les ressources Azure que votre implémentation pourrait créer.

remaining USD      = max(0, ceiling USD - accumulated estimated spend)
projected cost USD = sum(calibrated planned-dispatch estimates)
admission cost USD = projected cost USD × 3.0

La réserve d'admission d'un facteur trois est une marge de prudence prévue par la politique face à l'incertitude sur l'utilisation future des tokens, et non un intervalle de confiance statistique. Les totaux affichés ne sont arrondis qu'après addition des estimations de chaque ligne. Une prévision n'atteint le niveau de confiance medium que si la demande est bornée, les modèles et leurs tarifs sont connus, la table des tarifs est valide et le calibrage correspond à la révision actuelle de l'estimateur. Sinon, la squad indique cannot-confirm plutôt que de présenter une réponse optimiste.

Définir, hériter, remplacer ou supprimer un plafond#

L'héritage est lié à l'identifiant d'exécution enregistré. Une demande ultérieure qui poursuit cette exécution conserve son plafond ; un nouveau sujet en autopilot, un événement Watch ou une méta-exécution de fédération reçoit un nouvel identifiant et n'en hérite pas. La consommation estimée reste enregistrée même sans plafond actif, et tous les points de contrôle autres que ceux liés au coût continuent de s'appliquer.

# Set a $20 ceiling for this run
/squad request="implement the approved plan" mode=autopilot cost-ceiling=20

# Same run: $20 remains active because omission means inherit
/squad request="apply the review fixes"

# Same run: remove the guard explicitly
/squad request="continue without a cost ceiling" cost-ceiling=unset

Signification de chaque décision#

Poursuivre après une prévision de dépassement du plafond#

Avant de vous poser la question, la squad affiche le plafond, la dépense estimée cumulée, le montant disponible, le coût projeté de la demande restante, le coût d'admission prudent et la limite du mécanisme d'arrêt. Si vous poursuivez, elle conserve l'enregistrement over-ceiling d'origine et ajoute un cycle approved-over-ceiling auditable, lié à votre approbation. Celle-ci ne s'applique qu'au manifeste et à la base tarifaire inchangés ; une demande élargie, réévaluée en prix ou à faible niveau de confiance déclenche un nouveau point de contrôle.

Atteindre la limite ne bloque pas le projet indéfiniment. Pour reprendre, définissez un nouveau plafond positif supérieur à la dépense cumulée actuelle, supprimez explicitement le plafond avec cost-ceiling=unset, réduisez ou réévaluez en prix la demande restante puis relancez le contrôle préalable, ou commencez une nouvelle exécution. Réapprouver une valeur déjà dépassée n'est volontairement pas possible, car elle ne définirait plus une limite d'arrêt.

Exemples avec dépense cumulée#

Où consulter la décision#

La dernière décision synthétique se trouve dans state.json, sous currentRun.costPreflight. L'enregistrement reproductible est l'entrée ## Cost Preflight correspondante dans decisions.md, avec sa table de demande, les ensembles de créneaux évalués et autorisés, le motif et la référence de décision. Chaque entrée d'historique admise porte cette référence et consomme un créneau autorisé une seule fois, exactement. Les totaux estimés cumulés restent dans consumption.md ; les tarifs des modèles, les hypothèses de taille des lancements et le calibrage se trouvent dans consumption-rates.md.

Périmètre en fédération#

Le routage ordinaire d'une fédération applique le plafond fourni indépendamment à chaque sous-squad sélectionnée, que vous en désigniez une avec squad= ou que le méta-routage en sélectionne une ou plusieurs. Chaque sous-squad sélectionnée utilise son propre état, son estimation cumulée, son cycle de vie et sa limite d'arrêt, exactement comme une squad simple. La racine de la fédération enregistre le routage et les totaux de synthèse, mais conserve son Cost Preflight agrégé à not-requested.

Seul le mode=autopilot à l'échelle de la fédération, sans cible squad=, applique un plafond global à toutes les exécutions internes sélectionnées ainsi qu'à l'orchestration du coordinateur de fédération et du rédacteur de la racine. Il utilise le fichier consumption-rates.md de la racine de la fédération, ne transmet pas en plus le plafond aux exécutions enfants et compte les méta-créneaux terminés sur l'ensemble des cycles. Un dépassement global approuvé exécute une seule unité associant une sous-squad et le rédacteur de la racine à la fois, afin que la fédération puisse s'arrêter à la limite commune.

Étape de découverte — lorsqu'aucun document n'existe encore#

Deux points de contrôle précèdent le travail et répondent à des déclencheurs opposés. L'étape de découverte se déclenche lorsqu'il n'y a aucun artefact d'entrée et en produit un ; le contrôle des entrées se déclenche lorsqu'il y en a un et le valide. Le brief rédigé lors d'une session de découverte constitue lui-même un artefact d'entrée : il passe donc directement au contrôle des entrées.

no input artifact  →  discovery gate  →  brief  →  intake gate  →  research → plan → implement → review
   input artifact  →                              intake gate  →  research → plan → implement → review

Quand elle vous est proposée#

Le coordinateur ne propose cette étape que si les quatre conditions suivantes sont réunies :

• L'équipe utilise le profil product ou full — ce sont les seuls profils qui incluent d'emblée analyst, le rôle qui rédige le brief.
• Aucun PRD, BRD, spécification, user story, document de conception, transcription ou fichier que vous avez indiqué ne sert de base au tour.
• Le tour vise à faire avancer un plan, une réalisation ou un livrable — pas à répondre à une question ni à rechercher une information.
• La demande énonce un objectif (réduire les abandons lors de l'intégration) plutôt qu'une tâche définie (ajouter une nouvelle tentative au client webhook).

Dans tous les autres profils, cette étape reste silencieuse — aucune proposition, routage normal. C'est une différence volontaire avec le contrôle des entrées, qui demande une intervention lorsque son rôle manque : les entrées existantes ne doivent pas échapper à la validation, mais ne pas tenir un brainstorming que personne n'a demandé ne revient pas à omettre un contrôle. La question vous est posée une seule fois par sujet ; votre refus est enregistré et la proposition n'est jamais répétée.

Fournir discovery= fonctionne toujours, quel que soit le profil et même après un refus. Il s'agit d'une commande, et non d'une proposition : une squad autre que product nomme donc les rôles qu'elle doit ajouter et vous demande une fois votre accord avant de les lancer.

Niveaux de profondeur#

deep nécessite challenger, que seul full inclut d'emblée. Si vous le choisissez dans une squad product, le coordinateur propose d'ajouter le rôle ou d'exécuter standard à la place — il ne retire jamais silencieusement un rôle du niveau que vous avez choisi.

Ce que vous obtenez#

Les rôles lancés vous interrogent, une question à la fois, et s'arrêtent plutôt que de deviner lorsqu'ils ne peuvent pas vous joindre. Seul l'analyste écrit un fichier : un brief succinct nommé <date>-<topic-id>-brief.md à la racine de ses livrables, qui présente le problème, les raisons d'agir maintenant, les limites du périmètre, la mesure de réussite, les options envisagées, l'orientation retenue, les hypothèses et les questions ouvertes. Une entrée ## Discovery Verdict est ajoutée dans decisions.md en parallèle.

Les options écartées sont la partie à préserver. La valeur durable d'un brainstorming n'est pas l'idée retenue — celle-ci subsiste d'elle-même — mais la trace de ce qui a été rejeté et pourquoi. C'est ce qui évite que la squad rediscute les mêmes orientations trois tours plus tard.

Cette étape ne s'exécute jamais dans un parcours sans présence humaine. Personne n'est là pour répondre à la proposition : les données de l'événement déclencheur deviennent donc l'artefact d'entrée, que le contrôle des entrées évalue à la place.

Contrôle des exigences en entrée#

Lorsqu'une exécution s'appuie sur des artefacts d'exigences ou d'entrée — PRD, BRD, spécification, user story, document de conception, transcription ou fichier que vous indiquez à la squad — le coordinateur effectue un contrôle des entrées avant toute planification ou réalisation, pour vérifier leur exhaustivité, leur clarté, leur testabilité, leur cohérence et leur périmètre. Il enregistre un ## Intake Readiness Verdict dans decisions.md (Ready, Ready-With-Gaps ou Not-Ready).

En cas de Not-Ready, la squad ne construit pas sur des bases fragiles : elle sollicite l'analyste ou le responsable produit pour combler les lacunes bloquantes, puis revalide (dans une limite de deux cycles), et vous sollicite lorsqu'une lacune exige une décision humaine. Si aucun artefact d'entrée ne fonde l'exécution, ce contrôle reste silencieux et sans effet. Il est fourni avec les profils product et full ; les autres profils se voient proposer le rôle lorsqu'une exécution s'avère guidée par des exigences.

Lorsque l'entrée est un brief que l'étape de découverte vient de produire, la validation est confiée à un agent différent de celui qui l'a rédigé — par exemple le PRD Quality Reviewer pour vérifier un brief du PRD Builder. Un contrôle qui valide son propre résultat est une formalité, pas une vérification.

Approuver à distance (exécutions sans présence humaine ou sur VM)#

Si vous exécutez la squad sur une VM pour un travail de longue durée, choisissez le canal d'approbation github-issue lors de la création. À chaque point de contrôle, la squad ouvre une issue GitHub, vous l'attribue et vous @mentionne (vous recevez ainsi une notification push sur GitHub mobile), puis attend. Vous approuvez depuis votre téléphone par un commentaire — /approve, /approve-all, /changes: <note> ou /stop — ou une étiquette squad/*, sans toucher à la VM. Seul votre identifiant enregistré (ou un collaborateur du dépôt) peut approuver, et seuls ces mots-clés produisent un effet.

Les autres canaux sont webhook (uniquement une notification sortante Teams/Slack/Discord) et in-chat (le canal par défaut, qui exige votre présence devant le PC). Aucun canal n'exige que le package fournisse un mécanisme de transport d'e-mails ou de messages — si les outils d'un canal sont absents, l'approbation revient à la conversation, et la squad ne poursuit jamais à l'expiration d'un délai.

Configurer l'approbation à distance (une seule fois, uniquement pour github-issue)#

Les exécutions locales et les approbations dans la conversation n'exigent rien de plus. Pour approuver à distance une exécution sur VM, configurez le canal une fois :

1. Authentifiez-vous auprès de GitHub sur l'hôte d'exécution. Exécutez gh auth login (la CLI gh suffit sur une VM sans interface graphique) ou configurez le serveur MCP github officiel. Le package fournit une entrée de référence dans .github/skills/squad/mcp.template.json, que vous pouvez fusionner dans votre .vscode/mcp.json ; le MCP GitHub est privilégié lorsqu'il est présent, puis la squad se rabat sur gh, et enfin sur la conversation. Le jeton doit disposer des étendues repo + issues.
2. Installez le dispositif de surveillance des approbations. Copiez le workflow de référence .github/skills/squad/github-approval-watcher.workflow.yml vers .github/workflows/squad-approval-watcher.yml dans le dépôt qui héberge vos issues d'approbation, puis créez un commit. Il transmet votre réponse /approve, /approve-all, /changes: ou /stop pour que l'exécution reprenne — et seul un mot-clé reconnu provenant d'un identifiant autorisé produit un effet (le texte libre d'un commentaire n'est jamais exécuté comme une commande).
3. Choisissez github-issue lors de la création et indiquez au coordinateur l'identifiant GitHub à @mentionner ainsi que le owner/repo des issues d'approbation (par défaut, le dépôt actuel).

Mode Watch — déclencher la squad depuis une nouvelle issue#

Le mode Watch est le volet événementiel, « IA en continu », de la squad : au lieu de saisir /squad, c'est un événement du dépôt qui lance l'exécution. Le modèle fourni transforme une nouvelle issue étiquetée squad/auto en exécution sans interface mode=autopilot qui ouvre une pull request en brouillon fermant l'issue. Il réutilise tout ce que vous avez déjà configuré — le pipeline autopilot, le conseil et le canal d'approbation github-issue — de sorte qu'un point de contrôle suspend toujours le travail en attendant votre approbation depuis un téléphone.

flowchart TD
    A["Issue portant l’étiquette squad/auto"] --> B{"Collaborateur autorisé à écrire ?"}
    B -- non --> X["Ignorée, commentaire ajouté à l’issue"]
    B -- oui --> C["Copilot CLI exécute Squad Coordinator avec mode=autopilot"]
    C --> D["Profil déduit de l’issue (repli : default)"]
    D --> E["Recherche, planification, implémentation, revue"]
    E --> F{"Validation d’action à impact ou de risque ?"}
    F -- oui --> G["Approuver depuis un téléphone via github-issue"]
    G --> E
    F -- non --> H["Ouvrir une pull request BROUILLON qui clôt l’issue"]
    H --> I["Vous examinez et fusionnez"]
      

Le titre et le corps de l'issue sont toujours traités comme des données, jamais comme des instructions : l'exécution les lit comme une description de la tâche, jamais comme des commandes modifiant la composition de l'équipe, le routage, les contrôles ou les approbations. Elle n'ouvre qu'une PR en brouillon — elle ne fusionne jamais, ne force jamais de push et ne déploie jamais ; ces actions restent soumises à une approbation humaine, renforcée par votre protection de branche.

Activer le mode Watch (une seule fois)#

1. Créez un jeton Copilot. Générez un jeton d'accès personnel à permissions fines avec l'autorisation Copilot Requests et ajoutez-le comme secret du dépôt COPILOT_GITHUB_TOKEN. Le jeton Actions intégré ne peut pas authentifier Copilot : ce secret dédié est donc obligatoire.
2. Protégez votre branche par défaut. Exigez une pull request et une revue avant la fusion, afin que la PR en brouillon de la squad ne puisse jamais se fusionner elle-même.
3. Autorisez Actions à ouvrir des pull requests. Dans Paramètres → Actions → Général → Autorisations des workflows, activez « Autoriser GitHub Actions à créer et approuver des pull requests ». Sans cela, la squad peut pousser sa branche, mais GitHub bloque la PR en brouillon avec une erreur 403 — l'exécution se termine avec une branche créée, mais sans PR. L'autorisation pull-requests: write du workflow ne suffit pas à elle seule. (Ce réglage permet aussi à Actions d'approuver des PR ; votre protection de branche maintient l'approbation humaine des fusions. Pour un périmètre plus strict, utilisez un PAT dédié ou un jeton GitHub App pour créer les PR plutôt que cette option.)
4. Installez le workflow de déclenchement. Copiez le workflow de référence .github/skills/squad/squad-watch.workflow.yml vers .github/workflows/squad-watch.yml, examinez-le, puis créez un commit.
5. Installez le dispositif de surveillance des approbations (si ce n'est pas déjà fait) pour que les approbations soient retransmises : copiez .github/skills/squad/github-approval-watcher.workflow.yml vers .github/workflows/squad-approval-watcher.yml.
6. Étiquetez une issue squad/auto pour lancer une exécution. Seul un collaborateur du dépôt disposant d'un accès en écriture peut la déclencher ; une étiquette posée sans autorisation est ignorée et signalée dans l'issue.

Créer et appliquer l'étiquette squad/auto#

Le déclencheur est une étiquette GitHub ordinaire portant exactement le nom squad/auto. Créez-la une fois, puis appliquez-la à n'importe quelle issue pour lancer une exécution — toute personne disposant d'un accès en écriture peut effectuer les deux opérations. Dans l'interface GitHub : Issues → Étiquettes → Nouvelle étiquette, nommez-la squad/auto et enregistrez. Ou utilisez la CLI gh :

gh label create squad/auto --description "Hand this issue to the squad" --color 1D76DB
gh issue edit 42 --add-label squad/auto

L'étiquetage est le signal : l'événement issues: [labeled] se déclenche, le workflow vérifie que l'étiquette est squad/auto et que la personne qui l'a posée dispose d'un accès en écriture, puis l'exécution commence. Une seule exécution reste active par issue (réappliquer l'étiquette ne lance pas une seconde exécution concurrente). L'étiquette de déclenchement squad/auto est distincte des étiquettes d'approbation squad/* (squad/approved, squad/stop, …) que le dispositif de surveillance lit à un point de contrôle.

Le mode Watch est facultatif et limité au dépôt pour le moment : une issue sans étiquette ne déclenche rien, et les pull requests provenant de forks ne lancent jamais d'exécution privilégiée (le workflow n'utilise jamais pull_request_target).

Facultatif : un modèle de nouvelle issue pour squad/auto#

L'étiquetage manuel fonctionne très bien, mais un dépôt peut aussi ajouter un formulaire de nouvelle issue qui applique automatiquement l'étiquette squad/auto à la création, afin de soumettre une tâche à la squad en une seule étape. Copiez le formulaire de référence .github/skills/squad/squad-task.issue-template.yml vers .github/ISSUE_TEMPLATE/squad-task.yml, examinez-le, puis créez un commit — cela ajoute une option « Tâche Squad » à la page de création d'issue du dépôt, avec des champs pour la tâche, des critères d'acceptation facultatifs et une indication de profil facultative. C'est uniquement une commodité : elle est entièrement facultative, et une issue ordinaire étiquetée à la main lance une exécution exactement de la même manière.

Autres déclencheurs (au-delà d'une nouvelle issue)#

Une nouvelle issue étiquetée n'est que la première entrée de la table de correspondance entre événements et intentions du mode Watch. Le contrat (.github/instructions/squad/squad-watch-mode.instructions.md) définit comment tout événement du dépôt devient une exécution routée : le déclencheur fournit uniquement le contenu de l'événement sous forme de données, et la table de routage du coordinateur choisit le rôle. Le workflow de référence fourni les relie tous dans un seul fichier — une étape unique Préparer l'exécution autorise l'acteur, applique les protections relatives aux forks et construit le prompt routé pour l'événement survenu.

Chaque déclencheur passe par les mêmes garde-fous : une activation explicite (étiquette squad/* ou mot-clé /squad autorisé), un acteur autorisé, un contenu traité comme des données, des validations humaines pour toute action à impact, et un périmètre limité au même dépôt (les PR de forks sont ignorées et pull_request_target n'est jamais utilisé). Deux déclencheurs reposent sur le temps ou la branche : adaptez-les à votre dépôt avant de les activer — et supprimez ceux dont vous ne voulez pas :

# In .github/workflows/squad-watch.yml

on:
  schedule:
    - cron: '0 6 * * 1'      # when the maintenance sweep runs — adjust or remove
  push:
    branches: ['release/**'] # which pushes get a validation council — adjust or remove

Les déclencheurs issues, pull_request, issue_comment et workflow_dispatch ne nécessitent aucun réglage — ils sont conditionnés par les étiquettes et le mot-clé /squad, et restent donc inactifs tant que vous n'avez pas explicitement activé un élément.

Chaque exécution dispose de sa propre sous-squad#

Les exécutions sans présence humaine ne sont dignes de confiance que si vous pouvez voir ce qu'elles ont fait. Chaque exécution du mode Watch s'effectue donc dans une sous-squad de fédération dédiée à son événement déclencheur. L'issue #123 dispose de members/issue-123/, avec sa propre équipe, son journal de décisions, son historique par agent et son registre de consommation. Aucune exécution automatisée ne brouille la trace d'une autre, et des mois plus tard, vous pouvez encore ouvrir un dossier pour lire précisément quels rôles ont été exécutés, quelles décisions ils ont prises et pourquoi.

Vous n'avez pas à mettre en place la fédération au préalable. Le mode Watch initialise tout ce qui manque avant le début de l'exécution :

Les noms sont déterministes : vous savez donc toujours où chercher :

issue-123                   # an issue, or a /squad comment on it
pr-456                      # a PR review, or a /squad comment on the PR
sweep-2026-07-27            # a scheduled maintenance sweep
push-release-2-0-a1b2c3d    # a push to release/2.0 at commit a1b2c3d
dispatch-9911223344         # a free-form manual dispatch (workflow run id)

Deux propriétés de sécurité comptent ici. D'abord, le nom d'une sous-squad est un chemin de dossier ; il est donc dérivé uniquement des métadonnées structurelles de l'événement — numéros d'issue et de PR, références de branche, SHA de commit, identifiant d'exécution, date. Jamais du titre d'une issue ou du corps d'un commentaire, que n'importe qui peut rédiger. Ensuite, l'initialisation n'écrit jamais dans une sous-squad qu'elle n'a pas créée : si le nom dérivé entre en conflit avec l'une des vôtres, l'exécution dépose un commentaire sur l'issue source et s'arrête au lieu de l'écraser. Les sous-squads créées par Watch sont marquées Owner=watch-mode dans federation.md et enregistrées avec une route ciblée, indexée par référence, afin que vos demandes interactives /squad-federation n'y aboutissent jamais par accident.

Ces sous-squads sont conservées — elles constituent la piste d'audit, et rien ne les supprime automatiquement. En archiver ou en supprimer une est une action délibérée que vous devez demander.

Retrouver les détails d'un point de contrôle#

Lorsque la squad s'arrête à un point de contrôle — Cost Preflight, découverte, état de préparation des entrées, verdict du conseil, action à impact ou résultat final — le message dans la conversation reste volontairement bref pour ne pas noyer les échanges. Le raisonnement complet se trouve dans .copilot-tracking/squad/decisions.md, qui est en ajout uniquement : une nouvelle entrée ## Council Verdict est insérée dans le fichier (souvent au milieu, à côté d'entrées antérieures), pas toujours à la fin. Pour vous éviter de la chercher, chaque message de contrôle comporte une référence de décision — un lien profond vers la section exacte :

.copilot-tracking/squad/decisions.md#council-verdict-2026-07-07-residual-controls

.copilot-tracking/squad/decisions.md#cost-preflight-2026-09-13-run-001-round-002

L'ancre est le titre Markdown de l'entrée du verdict (en minuscules, avec des tirets à la place des espaces) : ouvrir le lien dans VS Code ou sur GitHub Pages vous mène donc directement au verdict, à sa table de constats par rôle et aux conditions — sans faire défiler le document. Le message de contrôle et le contenu de la notification incluent tous deux cette Decision Ref ; le pointeur State vers state.json et le fichier d'historique reste disponible en solution de repli.

Où chaque point de contrôle enregistre ses détails :

flowchart TD
    A["Validation requise (conseil / impact / finale)"] --> B["Message bref dans la conversation / notification"]
    B --> C["Lien direct Decision Ref"]
    C --> D["decisions.md#council-verdict-DATE-TOPIC — verdict, constats, conditions"]
    B -. repli .-> E["state.json + history — état de l’exécution et piste d’audit"]
    B --> F["notifications.md — journal de notifications en ajout uniquement"]
      

Première exécution (mode d'initialisation)#

Lorsqu'un projet n'a pas de fichier .copilot-tracking/squad/team.md, le coordinateur propose un profil de squad et demande s'il faut poursuivre. Si vous refusez, vous pouvez choisir un autre profil ou constituer une équipe personnalisée à partir d'un menu décrivant chaque rôle disponible — vous choisissez donc toujours parmi des agents réels et déployés, sans jamais en inventer. Il vous demande ensuite de choisir un canal d'approbation facultatif (github-issue pour l'approbation à distance ou depuis un téléphone, webhook ou in-chat), puis initialise team.md, routing.md, decisions.md, notifications.md, state.json et un répertoire history/. Il n'écrit jamais de fichiers avant votre confirmation. Par la suite, chaque appel /squad est routé selon l'équipe initialisée.

Sur un projet entièrement nouveau (sans squad), le mode d'initialisation propose d'abord un choix : une squad unique (par défaut), pour une seule équipe sur l'ensemble du dépôt, ou une fédération de plusieurs sous-squads nommées. Choisir une fédération passe la main à /squad-federation (voir ci-dessous) ; choisir une squad unique conserve le déroulement décrit ci-dessus.

Fédération — plusieurs sous-squads dans un même dépôt#

La fédération permet à un dépôt d'héberger plusieurs squads côte à côte — par exemple une sous-squad product pour l'équipe métier et une sous-squad azure pour les architectes. Elle est facultative et additive : un dépôt qui ne l'active jamais se comporte exactement comme une squad unique. Chaque sous-squad est une squad ordinaire — mêmes composition d'équipe, routage, décisions, historique et consommation — simplement enracinée dans .copilot-tracking/squad/members/<name>/ plutôt qu'au niveau supérieur.

# Build a federation (propose → confirm → create)
/squad-federation init

# Route a request to a specific sub-squad
/squad-federation request="draft the Q3 roadmap" squad=product

# Omit squad= and let meta-routing pick by keyword/domain
/squad-federation request="design the landing-zone network"

Une couche de coordination dans .copilot-tracking/squad/ contient federation.md (le registre des sous-squads) et meta-routing.md (motif de demande → sous-squad), ainsi qu'une trace des décisions et de l'historique à l'échelle de la fédération. Le Squad Federation Coordinator les lit, choisit la ou les sous-squads — ou respecte votre sélection explicite squad=<name> — et applique à chaque sous-squad son protocole normal par tour, dans le périmètre de sa propre racine.

Le coordinateur détermine le type de squad selon une règle simple : un fichier federation.md à la racine signifie une fédération (utilisez /squad-federation) ; un team.md à la racine signifie une squad simple (utilisez /squad comme auparavant). Les deux s'excluent mutuellement : un projet existant avec une squad unique reste donc inchangé — jusqu'à ce que vous choisissiez de le convertir (ci-dessous).

Chaque sous-squad possède un nom obligatoire, unique, en minuscules séparées par des tirets, car ce nom sert à la fois de dossier members/<name>/ et de sélecteur squad=<name> que vous saisissez. L'initialisation valide les noms avant de créer le moindre dossier et demande un autre nom en cas de conflit — elle ne réutilise ni n'écrase jamais silencieusement le répertoire d'une sous-squad. Les profils sont proposés pour chaque sous-squad à partir de votre dépôt et de votre demande (comme pour une squad unique), et vous pouvez accepter, changer un profil, ajouter ou retirer une sous-squad, ou constituer une équipe personnalisée pour chacune.

Convertir une squad unique en fédération#

Si vous avez commencé avec une ancienne version et une squad unique, puis souhaitez adopter une fédération pour un projet plus complexe, multiéquipe ou multidomaine, vous ne repartez pas de zéro. La conversion intègre votre squad existante dans une fédération en tant que première sous-squad, en déplaçant son état intact plutôt qu'en le reconstruisant.

# Promote the current single squad into a federation
/squad-federation promote

# Or ask the Squad Coordinator and accept its handoff
/squad request="I want to move this squad to a federation"

La conversion suit le parcours proposer → confirmer → migrer → initialiser → router et ne déplace ni n'écrit rien avant votre confirmation. Une fois confirmée, elle déplace toute l'arborescence d'état de la racine — team.md, routing.md, decisions.md, history/, la consommation et le reste — dans members/<name>/, en préservant octet pour octet vos journaux de décisions et d'historique en ajout uniquement, puis initialise la couche de coordination (federation.md, meta-routing.md et une trace de décisions et d'historique au niveau de la fédération). Ce déplacement retire le team.md de la racine : dès le tour suivant, /squad-federation prend donc en charge les tours, tandis que /squad détecte la fédération et lui passe la main.

L'opération est sûre et additive : c'est un déplacement, pas une suppression ou une réécriture ; elle refuse de s'exécuter en cas de conflit de nom ou si un federation.md existe déjà ; et un utilisateur qui ne convertit jamais son projet n'est aucunement affecté. Vous pouvez ajouter d'autres sous-squads aux côtés de celle qui vient d'être convertie dans le même tour, ou plus tard (voir ci-dessous).

Ajouter une sous-squad à une fédération existante#

Les fédérations évoluent. Une fois la fédération créée, envoyer init à son coordinateur (ou simplement demander d'ajouter une sous-squad) lance le mode d'extension — le même point d'entrée init construit une fédération dans un nouveau projet et étend une fédération existante.

# Add a new sub-squad to the current federation
/squad-federation init request="add a security sub-squad for threat modeling"

L'extension propose la nouvelle sous-squad (nom, profil, rôles) puis, après votre confirmation, l'initialise sous members/<new>/ et l'enregistre — en ajoutant une ligne dans federation.md, une route dans meta-routing.md et une entrée de décision de fédération. Elle est additive et non destructive : les sous-squads existantes ne sont jamais modifiées ni supprimées, et l'opération refuse de s'exécuter en cas de conflit de nom. Une fois terminée, la nouvelle sous-squad est accessible par squad=<new> ou par un mot-clé de méta-routage.

Les modes d'autonomie fonctionnent à l'intérieur d'une sous-squad ciblée. Avec squad=azure, autopilot exécute le pipeline complet de cette seule sous-squad. Omettez la cible squad= pour un autopilot à l'échelle de la fédération : il ordonne les sous-squads sélectionnées selon leurs dépendances (confirmées au premier point de contrôle), exécute à tour de rôle leur autopilot standard, fait remonter chaque contrôle d'action à impact et de risque au niveau de la fédération (en l'attribuant à la sous-squad qui l'a soulevé), applique un cost-ceiling global avec le cycle de vie et le comportement d'approbation encadrée décrits dans Contrôle d'admission des coûts, puis se termine par une unique validation consolidée du résultat final. Le pipeline interne de chaque sous-squad reste inchangé et aucune publication n'est jamais automatique.

# Target one existing sub-squad
      /squad-federation squad=azure mode=autopilot request="implement the approved infrastructure plan"

      # Or coordinate the work across the federation
      /squad-federation mode=autopilot request="implement the approved cross-squad plan"

Partager un enseignement (/squad-learn)#

La mémoire active des agents reste toujours locale à chaque utilisateur. Lorsqu'une exécution de squad fait émerger un enseignement durable et largement applicable, /squad-learn prépare une proposition expurgée des informations sensibles à partir de la mémoire locale et ouvre une pull request pour la partager. Il ne modifie jamais la mémoire active et ne pousse jamais sans votre approbation explicite.

/squad-learn
/squad-learn target=upstream
/squad-learn target=tenant learning="re-read reviewer verdicts before re-dispatching"

La commande suit le parcours découvrir → assainir → choisir la cible → ouvrir une PR. Deux cibles sont proposées : upstream transmet au package public pour que l'enseignement, une fois fusionné, bénéficie à tous les utilisateurs ; tenant transmet au dépôt privé interne au tenant de votre organisation pour que l'enseignement reste dans le tenant. Les deux passent par une revue humaine de la pull request, qui protège contre l'empoisonnement de la mémoire, les fuites de données et la dérive du contexte. La cible tenant exige que le dépôt privé d'enseignements existe au préalable (voir le modèle de dépôt pour le tenant) ; upstream fonctionne immédiatement.

Rechercher et exporter les connaissances de la squad (/squad-document)#

/squad-document recherche dans l'état de la squad — décisions, historique, routage, composition d'équipe et documentation du projet — pour répondre à une question ou produire un document ciblé. Au lieu de lire directement les journaux de décisions et les fichiers d'historique, vous décrivez votre besoin en langage naturel, et la commande synthétise une réponse étayée, écrite dans un fichier local.

/squad-document request="summarize all council verdicts from last week"
/squad-document request="what did the architect decide about the data layer?" format=html
/squad-document request="produce a stakeholder briefing" format=docx outputPath=docs/briefing.docx
/squad-document request="list all escalations" squad=product

Paramètres#

• request — (obligatoire) ce que vous souhaitez trouver ou documenter, en langage naturel.
• format={md|html|pdf|docx} — format de sortie (md par défaut). Revient au Markdown lorsque les outils du format demandé ne sont pas disponibles.
• outputPath=<path> — où enregistrer le fichier. Par défaut : docs/squad-document-<YYYY-MM-DD>.<ext>.
• squad=<name> — dans une fédération, limite la recherche à une sous-squad précise. En cas d'omission, recherche dans toutes les sous-squads.

Chaque affirmation du résultat s'appuie sur les artefacts de la squad — la commande cite les fichiers sources et signale explicitement les lacunes comme des questions ouvertes, plutôt que d'inventer du contenu. L'état de la squad est une entrée en lecture seule ; la commande ne modifie jamais les fichiers d'état.

Tableau de bord de gouvernance (/squad-governance-report)#

/squad-governance-report génère un tableau de bord de gouvernance HTML autonome à partir de l'état de la squad. Il visualise l'activité de coordination, les points de contrôle de gouvernance, la répartition des coûts, les tendances de lancement des rôles, les indicateurs de conformité et les principaux résultats, afin qu'un développeur ou une partie prenante puisse évaluer la santé de la squad d'un coup d'œil — sans lire manuellement les journaux de décisions ou les fichiers d'historique.

/squad-governance-report
/squad-governance-report output=docs/governance.html period=30d
/squad-governance-report squad=azure period=7d

Paramètres#

• output=<path> — où enregistrer le fichier HTML. Par défaut : docs/squad-governance-report-<YYYY-MM-DD>.html.
• squad=<name> — dans une fédération, limite le périmètre à une sous-squad précise. En cas d'omission, agrège toutes les sous-squads.
• period={all|30d|7d} — période à inclure (all par défaut).

Sections du tableau de bord#

Le rapport généré contient sept sections :

1. Contrôles de gouvernance — verdicts du conseil, contrôles des entrées, validations humaines et nombre de demandes d'intervention.
2. Verdicts du conseil — répartition des verdicts (feu vert / feu vert sous conditions / arrêt), avec les constats par rôle.
3. Répartition des coûts — coût estimé par rôle et par niveau de modèle.
4. Activité de lancement des rôles — nombre de lancements, modèles utilisés, taux de réussite et répartition des niveaux d'autonomie.
5. Risques et conformité — preuves issues des artefacts, vérification des tests, contrôle des actions à impact et demandes d'intervention ouvertes.
6. Chronologie des activités — vue chronologique des lancements et des décisions.
7. Principaux résultats — déploiements, issues créées, tests exécutés, fichiers modifiés et capacités livrées.

Le résultat est un fichier .html unique, sans dépendances externes — tous les styles sont intégrés : il s'affiche donc correctement lorsqu'il est ouvert dans n'importe quel navigateur ou partagé en pièce jointe.

Profils#

L'équipe initialisée par chaque profil :

Chaque profil inclut le socle méthodologique — researcher, lead, developer et tester — ainsi que scribe, de sorte que Recherche → Planification → Implémentation → Revue fonctionne dans tous les profils. Chaque profil y ajoute ses rôles spécialisés. Certains rôles ne sont initialisés que dans full, notamment challenger, qui met le plan à l'épreuve et le confronte à la recherche sur laquelle il repose, et prompt-engineer, qui rédige et examine les artefacts de prompt. Tout rôle du catalogue peut aussi être ajouté à n'importe quelle équipe sur demande — un profil est un ensemble initial pratique, pas une limite.

Certains rôles sont à activer explicitement et n'apparaissent dans aucun profil, pas même full, pour l'une de deux raisons. backlog-executor écrit des éléments de travail dans un projet Azure DevOps ou Jira actif, et une écriture dans un outil de suivi touche toute une équipe — notifications, abonnements et webhooks se déclenchent dès qu'un élément est créé — la squad ne met donc jamais cette capacité en place par défaut. qa-engineer, release-engineer et tous les rôles des packs sont à activer explicitement pour une autre raison : l'agent qui les assure est publié ailleurs et n'est simplement pas présent tant que vous ne l'avez pas installé ; une équipe ne doit jamais annoncer une capacité dont votre projet ne dispose pas. Dans les deux cas, le coordinateur propose le rôle la première fois que vous demandez un travail qui le nécessite, en précisant ce qu'il ferait et, si une installation est requise, la commande exacte. Acceptez, et il rejoint durablement votre équipe ; refusez, et la squad vous indique ce qu'elle ne peut pas faire plutôt que de le faire mal en silence. Voir Écritures dans le backlog ci-dessous.

Le conseil est dimensionné selon le travail, et non selon un quorum fixe. Seul full initialise tous les rôles du conseil (architect, security, cost-manager, product-owner, rai), et aucun autre profil n'en a besoin. Un conseil ne mobilise que les rôles correspondant aux angles que le travail touche — deux d'entre eux, les cinq, ou rai seul — et consigne chaque angle écarté avec sa raison. Lorsqu'un rôle du conseil nécessaire ne figure pas dans votre équipe, le coordinateur le propose comme extension du conseil. Si votre demande initiale appelle déjà un conseil, la proposition arrive à l'initialisation, dans la même confirmation que votre profil ; sinon, elle arrive lorsque le conseil se réunit. En mode autopilot, la squad ne pose la question que si un rôle nécessaire manque, et le Watch Mode signale le rôle à ajouter au lieu de l'ajouter. Refusez, et la squad consigne une renonciation au conseil et poursuit ; cette renonciation ne lève jamais une Risk Gate ni une action à fort impact.

Quatre rôles sont répertoriés, mais non sélectionnables, et leur présence est délibérée : devrel, networking, gcp et identity. Aucun agent ni skill ne les prend en charge, ici ou en amont ; un tel rôle serait donc une promesse plutôt qu'une capacité. Chacun indique pourquoi et ce qui permettrait de changer la situation, ce qui est plus utile qu'une lacune découverte au milieu d'un tour.

Packs#

Un profil répond à la question de quel type de travail s'agit-il ?. Un pack répond à sur quelles technologies repose-t-il ?. Vous choisissez exactement un profil et lui ajoutez zéro, un ou plusieurs packs : un domaine technologique se combine ainsi avec la préoccupation déjà retenue — un projet Power Platform qui nécessite aussi une piste d'audit associe compliance au pack power-platform, au lieu de vous obliger à choisir entre les deux.

La différence est structurelle, pas cosmétique. Un profil porte le socle méthodologique et peut livrer seul ; un pack ne contient que des spécialistes et doit s'appuyer sur un profil. C'est aussi pourquoi azure et modernization restent des profils : ils définissent l'orientation dominante d'une équipe plutôt qu'un complément.

pp-architect conçoit la solution : quels composants utiliser, comment configurer les environnements et les politiques DLP, comment articuler le modèle Dataverse et le cycle de vie de la solution. pp-connector crée des connecteurs personnalisés et les relie aux agents Copilot Studio. Tous deux conseillent et rédigent des fichiers ; aucun n'exécute pac sur votre tenant ni ne publie de connecteur : rien n'atteint donc un environnement actif sans votre intervention.

m365-agent-architect conçoit un agent déclaratif Microsoft 365 Copilot : ses capacités, la formulation de ses instructions et de ses amorces de conversation, et le choix de le définir dans un manifeste JSON ou en TypeSpec. m365-agent-integrator connecte cet agent aux systèmes sous-jacents — outils de serveur MCP, authentification via Entra et Microsoft Graph — et planifie le déploiement dans le tenant. Comme pour Power Platform, tous deux s'arrêtent à la transmission : aucun ne provisionne d'agent ni ne le publie dans votre tenant.

aws-architect conçoit les charges de travail AWS — services à retenir, organisation des comptes et de la zone d'atterrissage, et code CDK, SAM ou CloudFormation pour les construire — en s'appuyant sur les piliers AWS Well-Architected. aws-diagnose traite un incident en cours en lecture seule, depuis l'alarme CloudWatch jusqu'à une hypothèse de cause racine étayée par les métriques, les journaux et les traces ; il recommande une mesure d'atténuation sans jamais l'appliquer. AWS étant un pack plutôt qu'un profil, un projet multicloud associe azure au pack aws et bénéficie des deux, au lieu de devoir choisir. Il n'existe pas de pack gcp : rien en amont ne couvre Google Cloud, et la squad le dit plutôt que de laisser entendre qu'elle couvre tous les clouds.

Un pack est à activer explicitement. Ses rôles sont assurés par des agents publiés dans github/awesome-copilot plutôt que par ce package : hve-squad les référence donc au lieu de les distribuer — vous installez délibérément les ressources d'un pack, et aucun utilisateur n'hérite d'un domaine technologique qu'il n'a jamais demandé. Le coordinateur fournit la commande d'installation exacte lorsque vous appliquez le pack, ou la première fois qu'une demande nécessite un rôle que ce pack apporterait.

Vous avez rarement à vous rappeler l'existence des packs. La squad en propose un comme elle propose un profil — dès la première exécution si votre dépôt présente les signaux correspondants, ou lorsque votre demande nomme simplement le domaine (« transformer ce plan métier en solution Power Platform » suffit, même dans un dépôt sans fichier Power Platform). Elle en propose aussi un ultérieurement, la première fois qu'une demande nécessite un rôle que seul ce pack fournit. Une proposition n'est jamais une application : vous confirmez.

Demandez à la squad de retirer un pack lorsque vous avez terminé ce travail, et il disparaît de l'équipe. Le retrait n'enlève que les rôles dont ce pack est encore responsable — un rôle également apporté par votre profil ou un autre pack reste — sans altérer la trace : le journal de décisions et l'historique de chaque agent sont en ajout uniquement, donc le retrait ajoute une entrée plutôt que d'en effacer une. Tout ce que ces rôles ont déjà produit reste sur disque, et les ressources restent installées ; réappliquer le pack plus tard ne coûte donc rien.

Certains domaines technologiques ne sont pas des packs#

Deux domaines arrivent comme des extensions d'un rôle que vous avez déjà, plutôt que comme des packs, car aucun agent amont les prenant en charge n'a passé le contrôle de vérification de la squad — or un pack nécessite des rôles, qui nécessitent un agent. Power BI et Fabric (revue du modèle sémantique, optimisation DAX, conception de rapports, fondamentaux du Lakehouse) relèvent de data-scientist. L'ingénierie des applications d'IA (Microsoft Agent Framework, Semantic Kernel) relève de developer.

Il n'y a rien à appliquer pour l'un ou l'autre. developer figure dans tous les profils : l'ingénierie des applications d'IA est donc toujours disponible. data-scientist est initialisé par full et product ; dans tout autre profil, posez une question Power BI ou Fabric et la squad remarquera l'absence du rôle, puis proposera de l'ajouter, comme pour n'importe quel autre rôle. Cela fonctionne, mais vous le découvrez au moment du besoin plutôt qu'à la création de la squad — c'est le coût réel d'un domaine qui n'a pas pu devenir un pack.

Exemples de combinaisons#

Le profil découle de la nature du travail et le pack de la technologie : un même pack peut donc accompagner plusieurs profils. Ce sont des exemples, pas une liste fermée — n'importe quel pack se combine avec n'importe quel profil :

La ligne associant operations et aws illustre un cas qu'un profil seul n'aurait jamais pu couvrir : operations apporte déjà le spécialiste du dépannage Azure, et le pack place celui d'AWS à ses côtés ; une seule squad effectue donc le triage sur les deux clouds. La dernière ligne est l'autre cas qu'un profil ne pourrait pas couvrir — deux domaines technologiques à la fois, là où un profil vous oblige à en choisir un.

Profil, pack ou fédération ?#

Trois mécanismes peuvent ajouter des capacités, et il est facile de choisir le mauvais. La règle est simple :

Un même travail nécessitant une expertise supplémentaire appelle un profil et un pack. Ces rôles doivent partager un plan, une revue et une même conversation.

Deux flux de travail aux livrables et responsables distincts appellent une fédération. Ces équipes ont besoin d'être coordonnées, pas d'être réunies dans la même pièce.

Prenez une application Power Platform qui doit passer un audit. Avec profile=compliance pack=power-platform, il s'agit d'une seule squad : l'architecte Power Platform et le rôle chargé de la confidentialité sont mobilisés sur la même demande, et la décision DLP et la décision de conservation des données sont prises ensemble, dans un même plan et une même revue. Répartissez ce même travail entre une sous-squad compliance et une sous-squad power-platform, et vous obtenez deux équipes, chacune avec son journal de décisions et son historique, qui décident d'une même chose dans deux pièces sans jamais se rencontrer.

Il faut aussi savoir qu'une fédération ne donne pas accès à un domaine technologique plus vite qu'une squad simple. Chaque sous-squad est initialisée à partir d'un profil : un domaine technologique lui est donc ajouté par l'application du pack — exactement comme ailleurs. Créer une sous-squad portant le nom d'un domaine exige toujours le pack, tout en ajoutant un socle recherche-planification-réalisation-revue en double et un second ensemble de fichiers d'état, sans bénéfice supplémentaire.

Fédérez lorsqu'il y a réellement deux produits — par exemple une application Power Platform et une plateforme de données Azure, avec des responsables différents et des livraisons séparées. La première conserve son pack. Voir Fédération ci-dessus pour le fonctionnement des sous-squads.

Couche d'exécution Azure#

Le profil azure ajoute une capacité de réalisation et de déploiement Azure, inspirée d'un dépôt de modèles Azure déployables, livrée selon l'approche du package — sous forme de modèles de référence et d'agents de squad :

• Squad Azure Architect rédige la conception générale et détaillée (HLD/LLD), avec les modules AVM et les modèles de zones d'atterrissage.
• Squad IaC Author convertit cette LLD en Bicep ou Terraform sous infra/{track}/{project}.
• Squad Cost Manager produit des estimations indicatives et des constats d'optimisation des coûts selon le WAF.
• Squad Deployer effectue un contrôle préalable Azure Policy en lecture seule (affectations effectives et refus prévus), puis what-if/plan, et enfin le déploiement — strictement soumis au contrôle des actions à impact, jamais sans votre approbation.
• Squad As-Built Author inventorie les ressources déployées via Azure Resource Graph, construit une matrice de conformité à partir de l'état Azure Policy et rédige un guide d'exploitation ainsi qu'un plan de sauvegarde et de reprise après sinistre — le tout en lecture seule, sans jamais déployer ni modifier de ressources.
• Squad Azure Diagnose interroge Resource Health, les journaux Azure Monitor (KQL) et Resource Graph pour croiser et hiérarchiser les hypothèses, puis recommander des corrections pour les ressources défaillantes, sans jamais les appliquer.

Le skill azure-scaffold regroupe des modèles de référence purement documentaires qu'un agent de squad copie dans votre dépôt : un conteneur de développement (Azure CLI + Bicep, Terraform + TFLint, gh, Node, Python), des workflows de déploiement OIDC azure/login@v2 pour Bicep et Terraform, un assistant Setup-AzureOidc.ps1 (inscription d'application Entra, informations d'identification fédérées, RBAC, secrets GitHub), un Get-PolicyBaseline.ps1 en lecture seule ainsi qu'un workflow de gouvernance planifié, et la convention infra/bicep/{project} / infra/terraform/{project}. Rien ne s'exécute depuis le package — l'activation passe toujours par une copie et un commit explicites dans votre dépôt, et l'authentification utilise OIDC (aucun secret stocké).

Capacité MCP Azure#

Le contrôle préalable du Deployer, As-Built Author et Azure Diagnose utilisent tous la capacité azure-resource, qui privilégie le serveur officiel @azure/mcp lorsqu'il est configuré et se rabat automatiquement sur la CLI az et l'API REST Azure Resource Graph dans le cas contraire. La squad ne se bloque jamais à cause d'un MCP manquant pour une capacité de lecture comme celle-ci.

Pour connecter le serveur MCP Azure, fusionnez l'entrée de serveur azure de .github/skills/squad/mcp.template.json dans votre .vscode/mcp.json et rechargez VS Code. Le serveur s'authentifie via az login (DefaultAzureCredential) — aucun secret stocké. Vous pouvez demander au coordinateur de préparer cette configuration pour votre espace de travail VS Code :

/squad request="merge the squad MCP template into my VS Code workspace"

Écritures dans le backlog (Azure DevOps et Jira)#

Le rôle product-owner planifie un backlog et s'arrête à un fichier de transmission finalisé. Transformer ce plan en véritables éléments de travail est une étape séparée, soumise à approbation, qui relève du rôle backlog-executor, à activer explicitement — selon le même schéma que l'Azure Deployer : prévisualiser, approuver, puis écrire.

1. Demandez. Une fois le backlog planifié, demandez à la squad de créer les éléments :
   Copier

   /squad request="create these work items in Azure DevOps"

2. Acceptez le rôle. Si votre squad ne possède pas backlog-executor, le coordinateur propose de l'ajouter et précise l'outil de suivi et le projet dans lesquels il écrirait.
3. Examinez l'aperçu. Le rôle lit votre fichier de transmission et affiche chaque élément qu'il créerait ou modifierait — type, titre, parent, projet cible et champs qu'il renseignerait — ainsi que le nombre total. Rien n'a encore été écrit.
4. Vérifiez les avertissements. Il recherche également les éléments correspondants dans l'outil de suivi actif, signale les doublons probables avec leurs identifiants existants et retire les références internes de planification du texte sortant, afin qu'aucun chemin de suivi ni identifiant provisoire n'arrive dans votre backlog.
5. Approuvez. Une approbation couvre un seul lot. Modifiez la transmission, relancez l'opération ou ciblez un autre projet, et vous obtenez un nouvel aperçu et une nouvelle demande d'approbation.

Les écritures sont enregistrées élément par élément dans un fichier journal à côté de votre transmission : un lot qui échoue en cours de route reprend donc au premier élément non écrit, au lieu de créer des doublons. Rien n'est annulé automatiquement — tout ce qui a effectivement été écrit vous est signalé.

Deux limites sont volontaires. L'écriture exige que le serveur MCP Azure DevOps (ou, pour Jira, le skill jira) soit configuré ; contrairement aux capacités de lecture, il n'y a aucune solution de repli — le rôle s'arrête et vous indique ce qui manque au lieu d'accéder à votre outil de suivi par une voie que vous n'avez jamais configurée. Et puisque l'écriture dans un outil de suivi est une action à impact, une exécution du mode Watch sans présence humaine produit l'aperçu et s'arrête là ; l'écriture attend toujours une personne.

Modernisation#

Le rôle modernizer planifie les travaux de modernisation et les oriente vers le bon moteur d'exécution, depuis le seul point d'entrée /squad :

• Modernisation à pile technologique constante — mises à niveau des frameworks et dépendances, remplacement des API obsolètes, conteneurisation et préparation à la migration Azure. Le plan recommande le rôle developer de la squad pour les modifications ciblées, ou l'extension et la CLI officielles GitHub Copilot App Modernization de Microsoft pour les mises à niveau en masse.
• Changement de pile technologique — réécritures vers d'autres langages ou frameworks (par exemple un backend Node.js reconstruit en .NET, ou une application React reconstruite en Angular). Le plan formalise un contrat de comportement pour le système actuel, séquence une réécriture incrémentale selon le modèle du figuier étrangleur et confie l'exécution aux rôles developer et architect sous revue du conseil — jamais aux outils officiels de mise à niveau.

La modernisation s'exécute au niveau confirm : le rôle produit un plan qui conditionne l'implémentation, et les phases transverses passent par le conseil avant toute modification du code.

Présentations PowerPoint aux couleurs de votre marque#

Le rôle presenter (initialisé par les profils product et full) génère des présentations à partir de votre contenu. Fournissez-lui une fois votre .pptx de marque, et chaque présentation héritera de vos masques de diapositives, dispositions, couleurs de thème et polices. La règle de personnalisation graphique est fournie avec hve-squad et s'active automatiquement — vous n'avez jamais à copier un fichier, modifier une configuration ou repréciser le modèle à chaque demande.

Lorsque vous demandez une présentation, le coordinateur lance le PowerPoint Subagent, qui exécute le script du skill powerpoint nommé build_deck.py. La personnalisation graphique est appliquée au moyen du paramètre --template (-TemplatePath en PowerShell) : la génération hérite des masques de diapositives, des dispositions et du thème du modèle, élimine les diapositives d'exemple du modèle, puis ajoute uniquement celles définies dans votre contenu.

1 — Préparer un modèle de marque#

Ouvrez PowerPoint, créez un modèle 16:9 et enregistrez-le en .pptx avec :

• Des masques de diapositives portant vos arrière-plans, l'emplacement du logo et le pied de page — définis dans Affichage → Masque des diapositives.
• Des dispositions nommées auxquelles le générateur peut faire correspondre le contenu, au minimum Title Slide, Title and Content et Section Header.
• Des couleurs et polices de thème définies dans le thème (Masque des diapositives → Couleurs / Polices), afin que les références @theme_name correspondent à la palette de votre marque.

Vous n'avez pas besoin de laisser des diapositives d'exemple dans le fichier — une génération avec --template les élimine et ne conserve que les masques, les dispositions et le thème.

2 — Le placer à un emplacement stable#

Le modèle se trouve à un chemin fixe, pour que la squad sache toujours où le trouver :

.github/brand/pptx-brand-template.pptx

Vous n'avez pas à créer ce dossier vous-même. Si vous fournissez simplement votre .pptx à la squad (ou lui en indiquez un), elle propose d'y enregistrer une copie pour vous.

3 — Il s'applique automatiquement#

hve-squad fournit l'instruction de personnalisation graphique dans le package : lors d'un apm install, elle arrive dans .github/instructions/pptx-brand-template.instructions.md et s'active automatiquement. Son applyTo correspond à **/.copilot-tracking/ppt/** : le PowerPoint Subagent la lit donc chaque fois qu'il travaille sur une présentation — en utilisant votre modèle avec --template pour les reconstructions complètes et --source pour les reconstructions partielles. Si aucun modèle n'est encore présent, le générateur ne se rabat pas silencieusement sur une présentation neutre : il demande si vous disposez d'un .pptx de marque et propose de l'enregistrer pour vous.

4 — Aligner le contenu sur le modèle (facultatif, technique)#

Vous pouvez ignorer cette étape — la squad s'en charge pour vous. Pour un contrôle plus fin, déclarez le modèle et associez les noms de disposition dans content/global/style.yaml :

template:
  path: ".github/brand/pptx-brand-template.pptx"
  preserve_dimensions: true
layouts:
  title:   "Title Slide"
  content: "Title and Content"
  section: "Section Header"

Puis, dans le content.yaml de chaque diapositive, référencez les couleurs avec @theme_name plutôt qu'avec des valeurs hexadécimales codées en dur, afin que chaque diapositive s'adapte au thème défini par le modèle.

5 — Toujours valider#

La passe de validation du skill PowerPoint transforme une présentation correcte en présentation soignée. Elle effectue des contrôles géométriques (marges, débordements, espacements) et, en option, des contrôles visuels (chevauchements, contraste, alignement, espaces réservés non remplacés), puis itère pour corriger les problèmes. Laissez-la procéder par itérations plutôt que d'accepter la première génération — cette boucle fait la différence entre « c'est généré » et « c'est réussi ».

Ensuite, demandez une présentation conforme à votre marque sans reconfigurer le modèle à chaque demande :

/squad request="build a 6-slide overview deck for the booking service"

Registre des coûts d'exécution#

Chaque exécution estime le coût des modèles et la consommation de crédits IA de chaque lancement, afin qu'un projet puisse voir ce qu'une exécution a dépensé. Le Squad Scribe l'enregistre à trois endroits sous .copilot-tracking/squad/ :

• un bloc de consommation par lancement, ajouté à history/<agent>.md, avec le modèle retenu, la manière dont il a été déterminé, le niveau, l'estimation du nombre de tours de la boucle interne d'outils, les tokens estimés en entrée, en cache, en écriture de cache et en sortie, le coût estimé et les crédits estimés ;
• un registre agrégé consumption.md des membres, modèles et crédits, réparti entre une table Attribution (qui a été exécuté et avec quel modèle) et une table Utilisation et coût (tours, tokens, coût, crédits), avec le même ordre de lignes, des totaux pour l'exécution et une ligne de comparaison des coûts avec une référence manuelle à modèle unique ;
• une table des tarifs par token et par modèle dans consumption-rates.md — le seul endroit à mettre à jour lorsque les tarifs de GitHub Copilot changent.

Chaque chiffre est une estimation, et non un montant facturé : aucune télémétrie des tokens par lancement n'existe ; les nombres de tokens sont donc estimés, puis les coûts et les crédits en sont déduits (1 crédit IA = 0,01 USD). Les totaux de l'exécution apparaissent aussi dans state.json, sous currentRun.

Sélection du modèle par rôle (routing=)#

Comportement par défaut (routing=off) : aucun paramètre model n'est transmis aux lancements ; chaque agent utilise donc le modèle de son propre frontmatter ou celui de la session, exactement comme avant l'existence de cette fonctionnalité.

routing= propose quatre modes. Le mode est enregistré dans team.md et reste actif pour les demandes suivantes jusqu'à ce que vous le changiez : il suffit donc de le fournir une fois :

• off (par défaut) — aucun modèle n'est choisi ; team.md n'a pas de colonne Model.
• ranked — la squad choisit le modèle le mieux adapté au travail de chaque rôle parmi ceux proposés par votre hôte, et affiche chaque choix dans une colonne Model sous une ligne Model routing: ranked.
• Préversion uniquement v0.19.0-pre economy — comme ranked, sauf que cinq rôles d'implémentation à faible impact reçoivent le modèle le moins cher suffisamment adapté à leur travail ; affiché sous une ligne Model routing: economy. Sur option, et seulement après que vous avez accepté le compromis. Voir Mode economy ci-dessous.
• manual — vous choisissez une fois, avec des suggestions préremplies ; vos choix sont enregistrés dans la colonne Model sous une ligne Model routing: manual.

Comment les choix classés sont établis. Chaque rôle correspond à une classe de mission (research, planning, implementation, review, council, intake, bookkeeping). Le catalogue des modèles attribue à chaque modèle une note de 0 à 3 pour chaque classe. La squad choisit d'abord la meilleure adéquation, puis le coût pondéré le plus bas, puis la génération la plus récente au sein de la même famille de modèles. Elle ne départage jamais les ex æquo par le nom du modèle. Les rôles eux-mêmes et l'agent derrière chacun sont répertoriés dans references/roster-catalog.md du skill squad. Sur Copilot CLI, l'équipe initialisée utilise, par exemple, researcher → claude-opus-5.5, lead → gpt-5.6-sol, developer → gpt-5.3-codex, intake-validator → claude-sonnet-5.5 et scribe → claude-haiku-4.5.

Comment les choix manuels sont établis. Lorsque vous passez à routing=manual, à la création de la squad ou plus tard, le coordinateur vous interroge avant tout lancement. Vous pouvez accepter le modèle suggéré pour chaque rôle, choisir un modèle par classe de mission, puis modifier certains rôles individuellement. Chaque question ne présente que des modèles que votre hôte peut exécuter et qui respectent le seuil minimal Model Tier du rôle. Sur Copilot CLI et l'application GitHub Copilot, il s'agit de la liste exacte annoncée par l'outil task. VS Code n'annonce aucune liste : la squad propose donc des modèles du catalogue dont le prix est inférieur ou égal à celui du modèle de votre session ; si VS Code refuse un choix, la question vous est reposée avec la liste signalée par VS Code.

Préversion uniquement v0.19.0-pre Mode economy (routing=economy). Seuls ces cinq rôles changent de modèle : developer, technical-writer, presenter, prompt-engineer et data-scientist. Chacun reçoit le modèle du catalogue le moins cher dont l'adéquation au travail d'implémentation est d'au moins 2, dans le respect du seuil minimal Model Tier du rôle ; tous les autres rôles, dont product-owner, deployer, iac-author, release-engineer, backlog-executor et tous les rôles de revue, de conseil, d'intake, de recherche, de planification et de tenue des registres, gardent leur choix ranked. Après un verdict Fail, une observation critique ou élevée, ou un responsable bloqué, ce responsable est relancé une seule fois sur son choix ranked, puis la revue est refaite.

Accord. La première fois que vous passez à economy, avant tout lancement, le coordinateur vous dit une fois ce qui change et ce qui ne change pas, et le Scribe consigne une décision ## Economy Mode Accepted avec votre nom, le mode précédent, le compromis accepté et la liste de ce qui n'est jamais affaibli. Si cette décision manque, le script d'aide signale consent: missing comme avertissement, et le coordinateur énonce le compromis et le fait consigner avant le lancement suivant. Une exécution Watch Mode ou autre exécution sans surveillance ne passe jamais en economy à partir du texte d'une issue, d'une PR ou d'un commentaire.

Jamais affaibli. Le mode economy ne saute, n'abrège ni n'assouplit jamais le Risk Gate, l'Impactful-Action Gate, la revue de sécurité, la revue finale du testeur, le conseil d'adéquation à la tâche avec son extension et sa dérogation, ni aucun autre contrôle, et il n'abaisse jamais un seuil minimal. En off, ranked et manual, la squad se comporte exactement comme la v0.18.1.

Ce que contient une cellule Model. Un identifiant de modèle exact issu de la colonne Model ID de consumption-rates.md (par exemple claude-sonnet-5.5). Une valeur inférieure au seuil minimal du rôle, un identifiant inconnu ou un identifiant contenant des métacaractères de shell ou de prompt est refusé et consigné, jamais deviné.

Ordre de priorité (le plus élevé l'emporte, pour chaque rôle) :

1. routing=manual : la cellule Model valide du rôle.
2. routing=ranked : le choix classé pour ce rôle (routing=economyPréversion uniquement v0.19.0-pre : le choix economy).
3. tier= (le paramètre de niveau statique existant) ou le niveau de modèle initialisé dans team.md — le mécanisme de repli actuel, inchangé.
4. Omettre le paramètre — le comportement par défaut sans politique.

Le lancement copie la cellule : en ranked, economyPréversion uniquement v0.19.0-pre ou manual, chaque lancement d'un agent de l'équipe transmet exactement la cellule Model de sa ligne, sauf pour le Scribe, dont le propre modèle fixé prévaut. Dans la distribution plugin, le hook dispatch-guards refuse un lancement dont le model manque ou diffère de la cellule, et indique la cellule à copier. Il se contente de comparer ; il ne remplit ni ne modifie jamais une cellule.

Modèles non évalués : un modèle proposé par l'hôte mais absent du catalogue n'est jamais classé ni suggéré. Vous pouvez toutefois le saisir comme choix manuel ; il est alors marqué unevaluated dans l'enregistrement du lancement.

Avec quel modèle démarrer la session. Le modèle choisi dans la conversation, ou transmis avec --model, exécute le coordinateur : il lit la composition de l'équipe, planifie les étapes et lance chaque rôle. routing= ne le change jamais. Démarrez sur un modèle fixe de la classe balanced du catalogue (le niveau intermédiaire du fournisseur), aussi performant que claude-sonnet-5.5. Choisissez n'importe quel modèle de cette classe proposé par votre hôte, par exemple claude-sonnet-5.5, gpt-6-sol, gpt-5.6-terra, gemini-3.8-flash ou grok-4.7 ; le fichier references/model-catalog.md du skill squad contient la liste actuelle. Un modèle frontier-reasoning ajoute un coût à chaque tour du coordinateur sans améliorer le travail, que ranked confie déjà aux modèles de pointe lorsque cela apporte un bénéfice. Un modèle fast-lightweight risque davantage d'oublier des étapes obligatoires, comme copier la cellule Model ou transmettre au Scribe en même temps qu'il lance l'étape suivante. En auto, l'hôte peut changer le modèle du coordinateur en cours d'exécution, et le registre ne peut pas chiffrer sa part (voir Modèle fixe ou auto).

L'ancien paramètre models=<key>:<id>,... a été retiré. Si vous le fournissez, il n'est pas appliqué et le coordinateur vous oriente vers routing=manual.

Exemples :

# Switch to ranked selection; team.md gains a Model column showing each role's pick.
/squad request="implement the design" routing=ranked

# Switch to economy; the squad states the trade and records your consent first.
/squad request="update the getting-started guide" routing=economy

# Switch to manual selection; you are asked for the models before the request runs.
/squad request="design the data layer" routing=manual

# Return to the default; the Model column is removed.
/squad request="review the implementation" routing=off

# Switch the product sub-squad to manual selection; each sub-squad keeps its own picks.
/squad-federation squad=product routing=manual

Validation du registre#

Le Scribe effectue un autocontrôle d'exhaustivité des écritures exactement une fois par transmission, après que toutes les écritures ont été enregistrées. Ce contrôle recompte les enregistrements de lancement et les blocs de consommation dans chaque fichier d'historique touché pour confirmer qu'ils correspondent à ce qui a été écrit, et vérifie que les lignes par rôle et le total d'exécution du registre de consommation correspondent bien à la somme des blocs enregistrés sur disque.

Lorsque PowerShell 7+ est disponible, le coordinateur exécute aussi le script utilitaire Measure-SquadLedger.ps1 -Check (avec -SquadRoot <root> pointant vers la racine d'une squad) depuis le répertoire scripts/ du skill squad. Cet utilitaire en lecture seule recalcule tout le registre à partir des fichiers d'historique et de consumption-rates.md, et renvoie un code de sortie non nul s'il détecte l'une des conditions suivantes :

• Un écart entre le total d'exécution du registre et la somme de ses propres lignes.
• Un écart entre le total d'exécution du registre et, dans state.json, les totaux de currentRun. Un state.json manquant ou impossible à analyser fait échouer le contrôle ; une racine de fédération (signalée par federation.md) est en revanche consignée comme non applicable.
• Un échec du contrôle d'identité : les identités ordonnées des blocs de chaque fichier enregistrées dans le bloc ### Derivation du registre doivent former un préfixe ordonné des identités actuelles de ce fichier. Les écrasements, réordonnancements ou suppressions d'entrées d'historique font échouer ce contrôle ; les ajouts sont acceptés. Un simple -Check (sans -ExpectedHistoryCounts) n'émet qu'un avertissement pour les registres ne contenant aucune identité enregistrée (compatibilité avec l'ancien format). Combiné à -ExpectedHistoryCounts — l'autocontrôle du Scribe après écriture —, une section de dérivation sans aucune identité, ou sans identité pour certains seulement des fichiers touchés (collage partiel), provoque un échec plutôt qu'un avertissement.

Le Scribe ne recopie pas ces chiffres à la main. Sa seule voie d'écriture pour eux est Measure-SquadLedger.ps1 -Write, qui remplace les sections Attribution, Utilisation et coût, et Dérivation de consumption.md, puis définit dans state.json les deux totaux currentRun à partir du même calcul. Tous les autres octets des deux fichiers restent inchangés. Il refuse de s'exécuter et n'écrit rien sur une racine de fédération, en présence de -Check ou si l'un des fichiers ne contient pas la section à remplacer. Le coordinateur place la commande exacte dans chaque transmission au Scribe sous ledgerCommand, et le Scribe l'exécute en dernière écriture. Lancez -Check ensuite pour confirmer l'écriture.

Utilisation observée. Les estimations restent en place et l'utilisation réelle apparaît à côté. Avec -SessionLog auto, inclus dans ledgerCommand, le script lit le propre journal de session de l'hôte (~/.copilot/session-state/<session>/events.jsonl, écrit par Copilot CLI et l'hôte d'agents de VS Code), puis ajoute une section Utilisation observée (signalée par l'hôte) à consumption.md. Pour chaque agent, elle indique le modèle réellement exécuté, sa concordance éventuelle avec le registre et le total réel des tokens à côté de l'estimation. Elle fournit également les unités IA facturées par l'hôte pour l'ensemble de la session, coordinateur compris. Une table Sans HVE Squad compare l'exécution observée au même travail des rôles effectué avec un modèle unique et sans Scribe, les deux étant chiffrés selon la combinaison pondérée du catalogue. L'hôte rapporte un total de tokens par lancement, sans ventilation entre entrée, cache et sortie : cette comparaison est donc une estimation à périmètre comparable, pas une facture.

Conditions requises pour exécuter la squad#

• Un outil runSubagent ou task doit être activé pour que le coordinateur puisse lancer les membres de l'équipe.
• L'outil de mémoire devrait être disponible pour les notes durables de chaque agent sous /memories/repo/.
• Pour le canal d'approbation github-issue uniquement : une CLI gh ou un MCP github authentifié sur l'hôte d'exécution, ainsi que le workflow de surveillance des approbations installé. Les exécutions interactives et les approbations dans la conversation n'exigent ni l'un ni l'autre.

Vous pouvez recomposer la squad ultérieurement en modifiant .copilot-tracking/squad/team.md ou en demandant au coordinateur de changer de profil.

Exécuter sur d'autres hôtes#

La squad fournit à la fois des prompts et des agents. Copilot Harness pour VS Code, GitHub Copilot CLI et l'application GitHub Copilot exécutent tous les workflows Squad au moyen d'agents invocables par l'utilisateur. Les fichiers de prompt restent une solution de remplacement dans VS Code, mais sélectionner l'agent associé évite un appel intermédiaire et constitue la méthode d'appel qui fonctionne partout.

Sur la CLI, vous pouvez sélectionner un agent de manière interactive avec /agent, ou lancer une exécution sans interface avec --agent :

copilot --agent="Squad Coordinator" --prompt 'request="add input validation to the login form" profile=security'

Le skill squad est aussi découvert sur la CLI : /squad charge donc la procédure de fonctionnement de la squad dans l'agent avec lequel vous discutez déjà. Ce n'est pas la même chose qu'exécuter le coordinateur — sélectionnez l'agent lorsque vous voulez un véritable tour de squad.

Limites connues des hôtes#

• Le corps des agents est limité à 30 000 caractères hors de VS Code. Tous les agents de la squad sont fournis en dessous de cette limite ; la procédure se trouve dans le skill squad et est récupérée à la demande plutôt qu'injectée à chaque tour.
• model: doit être une chaîne unique. VS Code accepte aussi un tableau YAML ; la CLI rejette entièrement le fichier, et l'agent ne se charge jamais. La préférence de modèle par rôle doit figurer dans la colonne Model Tier de team.md.
• Les instructions limitées à un chemin ne se chargent que si applyTo correspond hors de VS Code ; un agent qui n'a pas encore touché l'état de la squad peut donc fonctionner sans elles. Le package fournit pour cette raison squad-floor.instructions.md avec le périmètre ** : ce fichier porte la discipline de lancement, la règle du Scribe comme rédacteur unique, les chemins d'état et la preuve de lancement, et s'applique quel que soit le fichier concerné.
• La substitution ${input:…} est réservée à VS Code. Les agents reprennent donc leurs entrées sous forme de noms de paramètres simples.
• Il n'existe pas d'outil de questionnement hors de VS Code. Les étapes de découverte et de contrôle des entrées vous interrogent une question à la fois ; dans VS Code, cela passe par vscode_askQuestions. Copilot CLI et l'application ne fournissent aucun équivalent : le rôle lancé renvoie donc sa question, et le coordinateur la pose dans le texte de sa réponse à la place. La discipline est la même sur tous les hôtes : une question bloquante sans réponse arrête le tour plutôt que de devenir une hypothèse enregistrée.

Modèle fixe ou auto#

Avec la sélection automatique du modèle, l'hôte route lui-même chaque demande et remplace le modèle fixé d'un sous-agent : un rôle fixé sur Sonnet peut être observé en train d'exécuter un modèle totalement différent. Le frontmatter est une demande, pas une garantie — pour un compte qui n'a pas accès au modèle fixé, le modèle de session est substitué silencieusement lors du lancement.

Le registre consigne donc ce que l'hôte a signalé pour chaque lancement, et non ce que la composition d'équipe demandait. Lorsque l'attribution des coûts compte, utilisez un modèle de session fixe (--model <id> sur la CLI, ou un modèle fixé dans le sélecteur de VS Code), afin que les niveaux privilégiant le coût définis pour l'équipe prennent réellement effet.