Agent Army

Que fait Agent Army ?

Un framework d'exécution parallèle à 2 couches. Le commandant est le modèle de plus haut niveau — Fable par défaut, ou Opus si c'est le modèle de session — et s'occupe de la réflexion : reconnaissance, composition, briefing, vérification. Il orchestre des essaims de modèles subordonnés dont les niveaux sont choisis par l'utilisateur au moment du déploiement (voir Niveau de Puissance). Chaque agent de la couche 1 dispose de sa propre fenêtre de contexte complète (pas une tranche). Chacun génère des sous-agents de couche 2 en dessous de lui. Le résultat est que de nombreux cerveaux indépendants fonctionnent en même temps — pas un seul cerveau divisé.

Commandant (vous — Fable ou Opus, le modèle de session)
 |
 |-- Couche 1 : Équipe (3 à 50+, chacun = 1M de contexte, niveau L1 selon le niveau de puissance)
 |    |-- Agent A (1M) -- Sous-agent A1, A2, ...  (niveau L2)
 |    |-- Agent B (1M) -- Sous-agent B1, B2, ...  (niveau L2)
 |    |-- Agent C (1M) -- Sous-agent C1, C2, ...  (niveau L2)
 |    |-- ... (pas de limite)

Essaim vs. armée : Un essaim divise une fenêtre de contexte entre les sous-agents — un seul cerveau, divisé. Une armée donne à chaque membre de la couche 1 sa propre fenêtre. Cette différence est le cœur de cette compétence.

Quand l'utiliser

• Grosses refontes couvrant de nombreux fichiers
• Migrations multi-fichiers (couleur, style, nommage, API)
• Audits de base de code étendus (sécurité, accessibilité, performance, code mort)
• Génération ou transformation de contenu en masse
• Toute tâche avec 6+ unités de travail indépendantes pouvant être exécutées simultanément

Quand NE PAS l'utiliser

• Moins de 6 unités de travail indépendantes — faites-le directement
• Fortes dépendances séquentielles où chaque étape a besoin du résultat de la précédente
• Modifications d'un seul fichier
• Tâches nécessitant une voix d'auteur cohérente sur l'ensemble des résultats (les agents parallèles dérivent)

Si la tâche ne correspond pas clairement, dites-le et proposez de la faire en ligne plutôt que de déployer une armée.

1. Chaque agent de la couche 1 DOIT générer 2+ sous-agents. Aucune exception. Si vous êtes sur le point de déployer un agent L1 sans sous-agents, ARRÊTEZ-VOUS et restructurez.
2. NE réduisez JAMAIS l'armée en silence. Respectez le niveau choisi par l'utilisateur. Si vous devez vous en écarter, dites-le à voix haute et expliquez pourquoi. 2b. NE rétrogradez JAMAIS les modèles en silence. Passez model: explicitement sur chaque appel d'agent au niveau de puissance choisi par l'utilisateur. L'omettre hérite du modèle de session — c'est une facturation Max Power silencieuse.
3. Les instructions de déploiement des sous-agents vont À L'INTÉRIEUR du briefing de la couche 1. Si elles manquent, les sous-agents ne seront jamais créés.
4. Rapportez au fur et à mesure que les agents se terminent : [Agent N/M terminé] nom : X fichiers modifiés, Y drapeaux.
5. Affichez le plan de l'armée et passez le portail de déploiement avant de déployer (Mode Complet). Le Mode Rapide compose le plan en interne mais passe toujours le portail.
6. Après chaque vague : exécutez la build ET la vérification de complétion fantôme (voir Vérifier). Un rapport vert d'un agent est une affirmation, pas une preuve.
7. "Continue" / "ne t'arrête pas" = mode continu : lancez un nouvel agent dès qu'un se termine. N'attendez pas, ne redemandez pas.

Taille de l'Armée

Confirmez un niveau avant de commencer. Présentez ce tableau :

| Niveau        | Agents L1 | Total avec Sous-agents | Est. Tokens |
|---------------|-----------|------------------------|-------------|
| Conservateur  | 3         | ~9                     | ~200-500K   |
| Standard      | 5-10      | ~15-30                 | ~500K-1.5M  |
| Agressif      | 10-20     | ~30-60                 | ~1.5-4M     |
| Maximum       | 20-50+    | ~60-100+               | ~4M+        |
| Personnalisé  | vous choisissez | vous choisissez    | varie       |

Par défaut, utilisez Standard sur "fais-le". Après la reconnaissance (Étape 3), recommandez un nombre spécifique basé sur ce que vous avez trouvé — par exemple "35 fichiers dans 6 domaines → Agressif : 8 agents L1, 2-3 sous-agents chacun (~22 total, ~2M tokens). Ajuster ?" Les estimations de tokens sont approximatives et évoluent avec la complexité de la tâche.

Niveau de Puissance

La taille définit combien d'agents ; la puissance définit quels modèles. Demandez les deux dans une seule question (AskUserQuestion fonctionne bien — taille et puissance en deux questions en un seul appel). Ignorez la question si l'utilisateur a déjà nommé un niveau de puissance ou des modèles explicites.

| Niveau de Puissance     | Commandant              | Couche 1 | Couche 2 | Meilleur pour                                   |
|-------------------------|-------------------------|----------|----------|-------------------------------------------------|
| Max Power               | Fable/Opus (session)    | Opus     | Opus     | Refontes complexes, migrations critiques en exactitude|
| Heavy (recommandé)      | Fable/Opus (session)    | Opus     | Sonnet   | La plupart des grandes tâches — orchestration intelligente, exécution rapide|
| Équilibré               | Fable/Opus (session)    | Sonnet   | Sonnet   | Migrations mécaniques avec des motifs clairs       |
| Économique              | Fable/Opus (session)    | Sonnet   | Haiku    | Grand volume, recherche/remplacement très simples    |

Règles :

• Le commandant est toujours le modèle de session — Fable ou Opus, au choix de l'utilisateur — et n'est jamais délégué. Si la session exécute Sonnet ou Haiku, dites à l'utilisateur de changer (/model ou claude --model fable) avant de déployer : la qualité du commandant est le plafond de la qualité de l'armée.
• Passez le modèle explicitement sur chaque appel d'agent : model: "<niveau L1>" pour les membres de l'équipe ; les briefs L1 instruisent model: "<niveau L2>" pour les sous-agents.
• L'escalade par agent est autorisée à tout niveau de puissance : un fichier lourd ou complexe (1000+ lignes, logique complexe) peut faire passer ce sous-agent à un niveau supérieur. Notez les escalades dans le plan de l'armée.
• Les vagues d'audit sont exécutées sur Opus quel que soit le niveau de puissance — des yeux neufs et plus forts sur le travail des exécutants. Les vagues de notification peuvent descendre à Haiku.

Protocole

Mode : Si le périmètre est déjà concret (chemins de fichiers, modifications exactes, niveau), passez à l'Étape 3 (Mode Rapide). Sinon, commencez à l'Étape 1 (Mode Complet).

Étape 1 : Prise en charge (Mode Complet)

Confirmez en une ligne si l'utilisateur a déjà donné le contexte : "Objectif : [X]. Périmètre : [Y]. Niveau : [Z]. Puissance : [P]. Démarrage." Sinon, demandez : objectif (une phrase), périmètre (fichiers/dossiers/"tout"), contraintes (ne touche pas X, correspond à Y), niveau et niveau de puissance.

Étape 2 : Point de contrôle Git

1. git status — prévenez en cas de modifications non validées, proposez de les stasher/valider d'abord.
2. git checkout -b agent-army/checkpoint-{timestamp} puis revenez en arrière. C'est le point de restauration.
3. Pas de dépôt git ? Prévenez qu'il n'y a pas de filet de sécurité et obtenez une confirmation explicite.

Étape 3 : Reconnaissance

1. Grep / Glob / Lire pour trouver chaque fichier affecté.
2. Comptez les unités de travail.
3. wc -l pour chaque fichier. Signalez les fichiers de 500+ lignes comme lourds → attribuez-les en solo.
4. Classez-les en domaines (par répertoire, graphe d'importations, type de fichier, motif de nommage).
5. Identifiez les dépendances partagées — fichiers de base importés dans plusieurs domaines. Traitez-les d'abord (Étape 5).
6. Identifiez la commande de build (package.json, Makefile, etc.).

Sortie : Fichiers : N | Lourds : [liste] | Domaines : [liste] | Déps partagées : [liste] | Cmd de build : [cmd]

Étape 4 : Composition

1. Agent de base pour les dépendances partagées — s'exécute avant la vague parallèle pour éviter les conflits entre dépendants.
2. Couche 1 : un agent par domaine ; divisez les grands domaines en plusieurs agents.
3. Couche 2 : 2+ sous-agents par agent L1, attribués par charge pondérée des fichiers, pas par nombre de fichiers :
   • Petit (<200 lignes) : 2-3 par sous-agent
   • Moyen (200-500) : 1-2 par sous-agent
   • Lourd (500+) : 1 par sous-agent, en solo
4. Nommez chaque agent. Attribuez chaque fichier à exactement un sous-agent — pas de chevauchement, pas de lacune.

Sortez le plan de l'armée. Mode Complet : marquez une pause pour "Procéder ?" Mode Rapide : résumé en une ligne, puis déploiement.

Portail de Déploiement

Sortez cette liste de contrôle dans votre réponse avant le déploiement. Ne la vérifiez pas mentalement — écrivez-la.

PORTAL DE DÉPLOIEMENT :
[ ] Chaque briefing L1 contient "Vous DEVEZ générer N sous-agents"
[ ] Chaque sous-agent est nommé avec des fichiers spécifiques attribués
[ ] Chaque fichier est possédé par exactement un sous-agent (pas de chevauchement, pas de lacune)
[ ] Les briefs L1 incluent les instructions complètes de déploiement des sous-agents
[ ] Le niveau correspond à la sélection de l'utilisateur
[ ] Le niveau de puissance est défini : model: "<niveau L1>" sur chaque appel L1 ; niveau L2 + escalades dans chaque briefing

Tous doivent PASSER. Tout ÉCHEC → corrigez le plan avant de déployer.

Étape 5 : Déploiement

1. Agent de base en premier (le cas échéant), au niveau L1. Attendez la fin.
2. Lancez TOUS les agents de la couche 1 en parallèle — run_in_background: true et model: "<niveau L1>" sur chaque appel, en un seul message.
3. Chaque agent L1 génère ses sous-agents L2 en parallèle (selon son briefing).
4. Rapportez chaque achèvement : [Agent N/M terminé] nom : résultats.

Étape 6 : Vérification

1. Re-scanner — relancez les recherches de l'Étape 3 pour les violations restantes.
2. Vérification de complétion fantôme — exécutez git diff --stat et croisez avec les rapports d'agents. Tout agent qui a rapporté "TERMINÉ, N fichiers modifiés" sans diff correspondant a menti ou n'a rien fait — réexpédiez-le. Faites confiance au diff, pas au rapport.
3. Build — exécutez la commande de build. Enregistrez RÉUSSI/ÉCHEC.
4. Résolvez les drapeaux inter-équipes à partir des rapports.
5. Sortez le rapport de l'armée :

Agents : N | Fichiers modifiés : N (confirmé par diff) | Ignorés : N | Build : RÉUSSI/ÉCHEC
Drapeaux : [liste] | Complétions fantômes détectées : N | Restauration : git checkout agent-army/checkpoint-{timestamp}

Vagues

Chaque vague est une armée nouvelle, plus petite et spécialisée différemment. Marquez une pause pour l'approbation de l'utilisateur avant chacune. Maximum 4 vagues.

Vague	Nom	Déclencheur	Objectif
1	Exécuter	toujours	effectuer les changements
2	Auditer	échec de la build, violations restantes, 20+ fichiers, ou drapeaux > 0	des agents neufs examinent la Vague 1 pour l'exactitude/les cas limites
3	Propager	les changements touchent les API/types/interfaces ; les tests ou la doc référencent d'anciens motifs	mettre à jour tests, docs, configs, appelants aval
4	Notifier	l'utilisateur opte-in	rédiger la description de PR, le changelog, le résumé Slack

Le rapport de chaque vague est la reconnaissance de la vague suivante. Après chaque vague, relancez Vérification ; arrêtez-vous lorsque le re-scannage est propre et que la build réussit, ou à 4 vagues.

Reprise / bloc-notes

Pour les exécutions multi-vagues ou interruptibles, écrivez .army-state.md après la Vague 1 : fichiers modifiés (confirmés par diff), drapeaux ouverts, problèmes non résolus, décisions. Si une exécution est tuée, l'invocation suivante lit ce fichier et reprend à partir de la dernière vague propre au lieu de redémarrer. Ignorez pour les tâches à vague unique.

Modèle de Prompt de la Couche 1

Voici ce que voient réellement les agents générés — la section la plus importante de la compétence.

Vous êtes [NOM_AGENT], spécialiste de [DOMAINE].

Objectif : [une phrase]
Motifs approuvés : [valeurs exactes — codes hexadécimaux, noms de classe, formes d'API]
Motifs interdits : [quoi supprimer/éviter]
Vos fichiers : [chemins absolus avec nombres de lignes]
Règles : [contraintes]. Ignorez les fichiers utilisant déjà des motifs approuvés (idempotence).
Signalez les problèmes en dehors de vos fichiers dans "Drapeaux pour le Commandant" — NE les corrigez PAS.

CRITIQUE : Vous DEVEZ utiliser l'outil Agent pour générer les sous-agents listés ci-dessous. Ne
faites PAS le travail vous-même. Ne SAUTEZ PAS la génération. Déployez TOUS les sous-agents dans un seul
message avec plusieurs appels à l'outil Agent, en passant model: "[NIVEAU_L2]" sur chaque appel
[notez les escalades : sauf "NOM" qui reçoit model: "[niveau supérieur]"].

Sous-agents :
- "[NOM]" : [fichiers avec nombres de lignes]
- "[NOM]" : [fichiers avec nombres de lignes]

Passez à chaque sous-agent : objectif, leurs fichiers, motifs approuvés/interdits, règles,
format de rapport. Une fois tous terminés, agrégez leurs rapports et vérifiez (en relisant
ou en grepant) qu'aucun motif interdit ne reste dans votre domaine avant de faire rapport.

Modèle de Prompt de la Couche 2

Vous êtes [NOM_SOUS_AGENT], travaillant sous [NOM_MEMBRE_EQUIPE].

Objectif : [une phrase]
Fichiers que vous possédez : [chemins absolus avec nombres de lignes — ne touchez que ceux-ci]
Motifs approuvés / interdits : [valeurs exactes à utiliser et supprimer]
Règles : [contraintes]. Ignorez les fichiers déjà corrects. Signalez les problèmes en dehors de
vos fichiers — NE les corrigez PAS.

Processus : lisez chaque fichier en entier → vérifiez l'idempotence → appliquez les motifs approuvés,
supprimez les interdits → relisez pour confirmer qu'aucun motif interdit ne reste.

Rapport : Fichiers modifiés (fichier : N remplacements), Fichiers ignorés (déjà corrects),
Drapeaux pour le Commandant, Problèmes, Statut (TERMINÉ/PARTIEL/ÉCHEC).

Format de Rapport

Chaque agent retourne :

## Rapport : [Nom]
Fichiers Modifiés :   [fichier : N remplacements]
Fichiers Ignorés :    [fichier : raison]
Drapeaux pour le Commandant : [problème ou "Aucun"]
Problèmes :           [problème ou "Aucun"]
Statut :              TERMINÉ / PARTIEL / ÉCHEC

Anti-patrons

Ce sont les modes de défaillance que cette compétence vise à prévenir. Si vous vous surprenez à en faire un, arrêtez-vous et corrigez.

• Embranchement fantôme — un agent L1 fait le travail lui-même au lieu de générer des sous-agents. Tout l'avantage de vitesse est perdu. Appliqué par la Règle Obligatoire 1 + le Portail.
• Complétion fantôme — un agent rapporte TERMINÉ sans rien modifier. Détecté par la vérification croisée git diff --stat, pas en faisant confiance au rapport.
• Réduction silencieuse — exécuter silencieusement 3 agents alors que l'utilisateur a choisi Agressif. Signalez toujours les écarts.
• Dérive de modèle — omettre model: sur les appels d'agent, de sorte que chaque sous-agent hérite silencieusement du modèle du commandant. L'utilisateur a choisi Économique et a été facturé Max Power. Appliqué par la Règle Obligatoire 2b + le Portail.
• Propriété qui se chevauche — deux sous-agents modifiant le même fichier → conflits et modifications perdues. Appliqué par la règle d'un seul propriétaire dans le Portail.
• Ignorer la base — toucher aux dépendants avant que les fichiers partagés ne soient mis à jour → cascade d'importations cassées. L'Agent de base s'exécute en premier.
• Armée pour un petit travail — 9 agents pour 4 fichiers, c'est plus lent (surcharge d'orchestration) et brûle des tokens. Voir "Quand NE PAS l'utiliser".

Gestion des Erreurs

• Un sous-agent échoue → l'agent L1 réessaie ses fichiers ou génère un remplaçant.
• Un agent L1 échoue → le commandant génère un remplaçant avec le même briefing.
• Échec de la build → diff par rapport à la branche de point de contrôle pour isoler la casse, puis lancez une vague de correction.
• Complétion fantôme → réexpédiez les fichiers de cet agent à un nouvel agent.
• Idempotence lors de la réexécution → les agents vérifient d'abord les motifs déjà appliqués, donc exécuter l'armée deux fois n'applique jamais deux fois.

Exemple commenté

Utilisateur

…

[tronqué pour la traduction]