Templates de prompts pour les équipes d'agents

Problème : Les équipes d'agents sont activées, et "monte une équipe pour aider sur mon projet" te donne un bazar. L'écart entre une équipe efficace et un feu de tokens se résume à comment le prompt est formulé. Une équipe productive a des rôles spécifiques, des limites de fichiers claires, et une ligne d'arrivée définie. Une mauvaise a trois réviseurs qui font du travail qui se chevauche.

Gain rapide : Essaie d'abord le prompt de revue de code parallèle (schéma #1 ci-dessous). C'est le schéma d'équipes d'agents le plus largement utile et tourne sur n'importe quelle codebase. Trois réviseurs, trois lentilles, une revue synthétisée. Tu verras le résultat en quelques minutes, et ça attrape des choses qu'un seul réviseur aurait manquées.

C'est un complément à l'aperçu des équipes d'agents. Commence là si tu n'as pas encore mis en place ta première équipe. Pour les contrôles et la configuration, saute aux contrôles avancés. Les dix prompts ci-dessous couvrent les workflows où l'exécution parallèle avec coordination active bat le travail série.

Schémas pour les équipes de code

1. Revue de code parallèle

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings. Use delegate mode so the
lead synthesizes a final review without doing its own analysis.

Pourquoi ça marche : un seul réviseur dérive vers un type de problème à la fois. Séparer les critères en domaines indépendants signifie que la sécurité, les performances et la couverture de tests reçoivent chacune une passe complète en même temps. Le chef assemble tout en une revue qui attrape des problèmes qu'aucun réviseur unique n'aurait vus. Les équipes de trois réviseurs font régulièrement remonter des problèmes que les revues single-pass laissent passer. Attends environ 2-3x le coût en tokens d'une revue en session unique. Ça vaut la couverture.

Le mode délégation compte. Sans lui, le chef tend à faire sa propre revue et la mélange maladroitement avec les résultats des coéquipiers. Avec le mode délégation activé, le chef se concentre entièrement sur la coordination et la synthèse.

2. Débogage avec des hypothèses concurrentes

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk
to each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

Pourquoi ça marche : une structure de débat bat le biais d'ancrage. L'investigation séquentielle se coince sur la première théorie plausible et finit par essayer de la confirmer. Plusieurs investigateurs indépendants qui essaient activement de se démentir mutuellement signifient que la théorie qui survit est plus proche de la vraie cause racine.

Ce schéma fait aussi remonter des liens inattendus. Quand le coéquipier #3 trouve une fuite mémoire et que le coéquipier #1 chassait un comportement de timeout, ils peuvent faire le lien directement. Pas de chef au milieu. Ce canal direct est ce qui sépare les équipes d'agents des schémas de sous-agents.

3. Implémentation de fonctionnalité full-stack

Create an agent team to implement the user notifications system.
Spawn four teammates:
- Backend: Create the notification service, database schema, and API endpoints
- Frontend: Build the notification bell component, dropdown, and read/unread states
- Tests: Write integration tests for the full notification flow
- Docs: Update the API documentation and add usage examples

Assign each teammate clear file boundaries. Backend owns src/api/notifications/
and src/db/migrations/. Frontend owns src/components/notifications/.
Tests own tests/notifications/. No file overlap.

Pourquoi ça marche : les limites au niveau des fichiers tuent les conflits de fusion. Chaque coéquipier sait quels répertoires il possède, et la liste de tâches partagée garde tout le monde sur la même page. Dès que le coéquipier backend pose le contrat API, le coéquipier frontend le récupère. Ils regardent tous les deux la même liste.

Sans limites explicites, deux coéquipiers modifient le même fichier et se rentrent dedans. La propriété au niveau répertoire est le seul détail le plus important dans un prompt d'implémentation. Ce schéma correspond directement au modèle d'exécution en vagues du guide workflow, où les contrats upstream alimentent les prompts de spawn d'agents parallèles.

4. Enregistrement de décision d'architecture

Create an agent team to evaluate database options for our new analytics feature.
Spawn three teammates, each advocating for a different approach:
- Teammate 1: Argue for PostgreSQL with materialized views
- Teammate 2: Argue for ClickHouse as a dedicated analytics store
- Teammate 3: Argue for keeping everything in the existing MongoDB

Have them challenge each other's arguments. Focus on: query performance
at 10M+ rows, operational complexity, migration effort, and cost.
The lead should synthesize a decision document with the strongest arguments
from each side.

Pourquoi ça marche : la délibération bat un seul agent qui pèse les options tout seul. Chaque coéquipier s'engage dans une position et cherche les failles dans les autres. Le chef ne rédige que les arguments qui survivent au défi.

Celui-ci est particulièrement utile pour les décisions où chaque option a de vrais compromis et pas de gagnant évident. Une seule session tend à en choisir une tôt et à la rationaliser pour en faire la réponse. La structure adversariale force une vraie évaluation de chaque alternative.

5. Analyse des goulots d'étranglement

Create an agent team to identify performance bottlenecks in the application.
Spawn three teammates:
- One profiling API response times across all endpoints
- One analyzing database query performance and indexing
- One reviewing frontend bundle size and rendering performance

Have them share findings when they discover something that affects
another teammate's domain (e.g., slow API caused by missing DB index).

Pourquoi ça marche : la communication inter-domaines est là où les équipes d'agents battent les sous-agents. Quand l'analyste de base de données repère un index manquant qui explique l'endpoint lent du coéquipier API, il le transmet directement. Les sous-agents ne peuvent pas faire ça, parce qu'ils ne rapportent qu'à la session principale et ne se parlent jamais.

Une chasse aux performances bénéficie aussi de la liste de tâches partagée. Pendant que chaque coéquipier enregistre des problèmes avec des niveaux de gravité, le chef voit le tableau se former en temps réel et redirige les efforts vers les cas les plus graves.

6. Classification d'inventaire

Create an agent team to classify our product catalog. We have 500 items
that need categorization, tagging, and description updates.
Spawn 4 teammates, each handling a segment:
- Teammate 1: Items 1-125
- Teammate 2: Items 126-250
- Teammate 3: Items 251-375
- Teammate 4: Items 376-500

Use the classification schema in docs/taxonomy.md. Have teammates
flag edge cases for the lead to review.

Pourquoi ça marche : le travail data-parallèle s'adapte linéairement avec les coéquipiers. Chacun travaille sa tranche indépendamment, marquant les éléments ambigus pour une passe humaine. Quatre coéquipiers traitant 125 éléments chacun va environ 4x plus vite qu'une session traitant 500.

Le même schéma s'adapte à n'importe quelle opération en masse. Tagger des tickets de support, catégoriser des pages de doc, normaliser des enregistrements de base de données, mâcher des fichiers CSV. La clé est de diviser par limites de données, pas par fonction.

Schémas pour les équipes non-code

Les équipes d'agents ne sont pas que pour le code. Tout ce qui bénéficie de perspectives parallèles et d'une coordination serrée est sur la table. Les prompts ci-dessous couvrent la recherche, le contenu et la stratégie de campagne.

7. Sprint de recherche de campagne

Create an agent team to research the launch strategy for [product].
Spawn three teammates:
- Competitor analyst: study competitor ad copy, positioning, and pricing
- Voice of customer researcher: mine reviews, Reddit threads, and forums
  for pain points and language customers actually use
- Positioning stress-tester: take findings from both teammates and
  pressure-test our current positioning against what they discover

Have them share findings and challenge each other. The lead synthesizes
a strategy document with positioning recommendations.

Pourquoi ça marche : le chercheur concurrent trouve des lacunes de marché. Le coéquipier voix du client vérifie si les vrais acheteurs se soucient vraiment de ces lacunes. Le testeur de positionnement prend les deux entrées et essaie de casser ton message avec elles. Trois lentilles, une synthèse, la sortie de chaque coéquipier alimentant les autres.

Compare ça à trois sessions de recherche séparées. Tu te retrouverais avec trois rapports indépendants et passerais du temps à les recroiser à la main. Les équipes d'agents font les croisements automatiquement via la messagerie inter-agents.

8. Construction de landing page avec revue adversariale

Create an agent team to build the landing page for [offer].
Spawn three teammates:
- Copywriter: develop messaging, headlines, and body copy
- CRO specialist: design conversion structure, CTA placement, and flow
- Skeptical buyer: review everything as a resistant prospect, flag
  weak claims, missing proof, and friction points

Require plan approval before any implementation.

Pourquoi ça marche : l'approbation du plan attrape les mauvaises directions avant qu'elles brûlent des cycles. Le réviseur adversarial trouve des trous que les coéquipiers focalisés sur la construction glissent dessus. Les vrais acheteurs sont sceptiques. Ton équipe devrait l'être aussi.

L'approbation du plan compte le plus ici parce que le copy de landing page est coûteux à réécrire. Attraper une proposition de valeur faible à l'étape du plan prend des minutes. L'attraper après un build complet prend des heures.

9. Exploration de créatifs publicitaires

Spawn 4 teammates to explore different hook angles for [product].
Each teammate develops one direction with headline variations,
supporting copy, and a rationale for why the angle works.
Have them debate which direction is strongest.
Update findings doc with consensus and runner-up options.

Pourquoi ça marche : un seul agent qui explore seul s'ancre sur la première bonne idée. Quatre agents qui essaient activement de surpasser les autres produisent du créatif bataillé. La structure de débat signifie que l'angle gagnant a survécu à un vrai défi, pas au monologue interne d'une seule session.

Ce schéma produit des angles qu'une seule session n'aurait jamais explorés. Quand le coéquipier #2 pousse contre l'approche du coéquipier #1, le coéquipier #1 affine souvent son angle en quelque chose de plus fort plutôt que de l'abandonner. La pression compétitive élève le plancher de qualité.

10. Pipeline de production de contenu

Create a team for this week's content calendar.
Spawn three teammates:
- Researcher: identify search intent gaps and competitive opportunities
- Writer: draft content based on research findings
- Quality reviewer: run each piece through clarity, proof, and SEO checks

Chain tasks so the researcher finishes before the writer starts,
and the reviewer checks each piece before marking it complete.

Pourquoi ça marche : recherche parallèle et portes qualité séquentielles. Le chercheur et l'auteur peuvent se chevaucher sur différentes pièces pendant que le réviseur attrape les problèmes avant que quoi que ce soit soit publié. QA intégré sans processus de revue séparé.

Le chaînage des tâches est le détail clé. Sans lui, les trois coéquipiers démarrent en même temps et l'auteur rédige à l'aveugle sans recherche. Les dépendances de tâches explicites via la liste de tâches partagée imposent le bon ordre d'exécution. Pour plus sur le chaînage des tâches entre agents, voir les workflows asynchrones.

Une progression sur trois semaines

Nouveau dans les équipes d'agents ? Commence simple et monte en puissance. Sauter directement dans un prompt d'implémentation à cinq coéquipiers est une recette pour la confusion. Cette progression sur trois semaines construit l'intuition pour savoir quand les équipes ajoutent de la valeur et quand elles ajoutent de la surcharge.

Semaine 1 : recherche et revue

Prends une PR qui a besoin de revue. Active les équipes d'agents, puis lance :

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

Trois réviseurs, trois lentilles, une revue. Tu vas regarder les coéquipiers travailler dans la liste de tâches, échanger des résultats, et livrer. Risque faible, apprentissage élevé. Dans le pire cas, tu obtiens une revue incomplète que tu finis manuellement.

Semaine 2 : débogage avec débat

Prends un rapport de bug et lance le schéma d'hypothèses concurrentes :

Users report intermittent 500 errors on the checkout endpoint.
Spawn 3 teammates to investigate different hypotheses:
- One checking database connection pooling
- One investigating race conditions in the payment flow
- One analyzing server resource limits
Have them share findings and challenge each other's theories.

Ça t'enseigne comment la communication inter-agents fonctionne vraiment en pratique. Regarde comment les coéquipiers partagent des preuves, comment ils poussent contre les théories faibles, et comment le consensus se forme. La liste de tâches partagée est là où la plupart de cette coordination devient visible.

Semaine 3 : implémentation

Une fois que les schémas de coordination te semblent naturels, essaie un build de fonctionnalité avec des limites de fichiers claires :

Create an agent team to build the webhook system.
Assign directory-level ownership to prevent conflicts.
Use delegate mode for the lead.

À la semaine trois tu auras une idée de quand les équipes se rentabilisent et quand une seule session ou une approche de sous-agent est le meilleur choix. La plupart des développeurs trouvent que les équipes fonctionnent mieux pour les tâches nécessitant trois flux de travail indépendants ou plus avec au moins une communication inter-domaines.

Ce qui fonctionne vraiment

Après des dizaines de sessions d'équipes d'agents, ces schémas tiennent dans tous les workflows ci-dessus :

• Sois spécifique sur les rôles : "un sur la sécurité, un sur les performances" bat "des réviseurs." Des rôles vagues produisent du travail vague.
• Définis les limites de fichiers : la propriété au niveau répertoire tue les conflits de fusion. Non négociable pour les tâches d'implémentation.
• Inclus des critères de succès : "Report findings" ou "update the decision doc" donne à chaque coéquipier une ligne d'arrivée.
• Utilise le mode délégation pour la pure coordination : empêche le chef de faire le travail lui-même. Le travail du chef est la synthèse, pas la production.
• Exige l'approbation du plan pour les travaux risqués : attrape les mauvaises directions avant qu'elles brûlent des tokens. Critique pour les tâches créatives et d'implémentation.
• Laisse les coéquipiers débattre : la friction bat l'accord. Les schémas de débat surpassent systématiquement ceux cherchant le consensus.
• Garde la taille de l'équipe à 3-5 : plus de coéquipiers signifie plus de surcharge de coordination et des coûts en tokens plus élevés. Au-delà de cinq, le volume de communication grignote le gain de parallélisme.
• Associe le schéma à la tâche : le travail data-parallèle (classification, traitement) se divise par limites de données. Le travail fonctionnel (implémentation de fonctionnalité) se divise par domaine. Le travail évaluatif (décisions d'architecture, créatif) se divise par perspective.
• Accélère le chef avec le mode rapide : active le mode rapide pour le chef pour une coordination plus réactive pendant que les coéquipiers tournent à vitesse standard pour garder les coûts bas.

Pour les meilleures pratiques, le dépannage et les limitations connues, voir les meilleures pratiques des équipes d'agents. Pour les modes d'affichage, la gestion des coûts en tokens et les hooks de porte qualité, voir les contrôles avancés.

Ces prompts fonctionnent tels quels pour tout utilisateur de Claude Code avec les équipes d'agents activées. Commence avec le prompt de revue de code cette semaine. La surcharge est faible, et chaque prompt ci-dessus est un point de départ testé pour un workflow que tu utilises déjà.