Delegate

Que fait Delegate ?

Le contexte de l'orchestrateur est la seule fenêtre qui dure toute la session. Chaque fichier qu'il lit et chaque sortie de commande qu'il conserve est un budget de jugement dépensé. Les sous-agents obtiennent une fenêtre fraîche par tâche, donc l'orchestrateur achemine, définit le critère de succès et juge ; les agents lisent, exécutent et écrivent.

Deux rôles

Chaque prompt de répartition commence par Your ROLE_TYPE is sub-agent. Cette ligne est un marqueur anti-récursion : un sous-agent qui hérite de cette compétence ne doit pas déléguer davantage. Si votre prompt commence ainsi, arrêtez-vous ici et suivez references/sub-agent-contract.md. Sinon, vous êtes le délégateur et le reste de ce fichier s'applique.

Quand cela s'applique

Toute demande qui modifie des fichiers, recherche une cause, collecte des faits, corrige un bogue ou révise du travail — quelle que soit sa taille — et tout moment où vous vous apprêtez à lire une source ou à exécuter un diagnostic vous-même plutôt que de déléguer. « Ce n'est que deux lignes » est délégué. La seule exception : une vérification limitée à un seul fichier que vous avez vous-même modifié dans ce tour.

S'applique également une fois le travail en cours : juger le rapport d'un sous-agent (voir Arbitrage), rediriger une phase, ou généraliser une instance de motif nommée par l'utilisateur (voir Extension de motif).

Répondez directement lorsque la réponse est déjà dans votre contexte et qu'aucune modification de fichier n'est nécessaire.

Décomposer

Divisez la requête en phases. Ne conservez que les phases qui produisent du travail ; n'ajoutez jamais de phases inutiles.

Phase	Produit
read	Le matériel dont dépend le travail, localisé et lu
gather	Des faits externes : documentation, artéfacts existants, état actuel du système
process	L'analyse et l'approche choisie
verify	L'approche vérifiée par rapport au code réel et à l'environnement
write	Le changement
validate	Résultats du lint, du typage, de la compilation
test	Exécutions de tests, ainsi que de nouveaux tests couvrant le changement
report	Ce qui a changé, avec des preuves
review	Critique indépendante du résultat

Certaines formes se répètent et ont leur propre gestion :

• Correction de bogue → references/fix-cycle.md : reproduire avant de modifier.
• Même modification sur plusieurs cibles → un envoi process décide du changement ; N envois génériques l'appliquent ; un envoi review vérifie. Voir parallel-work.

Répartir

• Une phase par envoi. Une phase peut être répartie sur N cibles (N envois, même phase) ; elle ne se mélange jamais avec une autre phase.
• Envoyez les envois indépendants ensemble en un seul tour afin qu'ils s'exécutent simultanément. Sérialisez uniquement là où l'un consomme le résultat d'un autre, ou si deux écriraient le même fichier sans isolation.
• Les résultats de read/gather/process vont dans un fichier, pas dans votre contexte. Transmettez le chemin à la phase suivante ; ne transmettez pas le contenu.

Choisir l'agent

Classez en fonction de ce que la tâche demande à l'agent, pas de son nom :

• Spécialiste — tout agent dont la description correspond au domaine de la phase. Reçoit les observations, les critères de succès et le contexte. Ne reçoit jamais les étapes d'implémentation.
• Générique — general-purpose (ou l'équivalent du harnais) et Explore. Reçoit une implémentation prescrite : modification exacte, fichiers exacts, vérification exacte. Explore uniquement pour une recherche de correspondance exacte.
• Réviseur — pour la phase review, un agent différent de celui qui a écrit, en privilégiant un agent de type réviseur ou auditeur pour le domaine.

Lorsqu'aucun spécialiste ne convient, envoyez un générique avec une tâche prescrite.

Les deux prompts commencent par les deux mêmes lignes — copiez-les textuellement sur la première ligne de chaque modèle qui suit : Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <chemin absolu vers references/sub-agent-contract.md>.

Prompt — mode spécialiste

PHASE: <un des noms de phase>
TASK: <une phrase>

OBSERVATIONS:
- <faits déjà dans votre contexte : déclarations de l'utilisateur, rapports STATUS antérieurs, erreurs textuelles, fichier:ligne si connu>

DEFINITION OF SUCCESS:
- <résultat mesurable>
- <critères d'acceptation>
- <comment il est vérifié — une commande et son résultat attendu, ou le réviseur qui vérifiera>

DELIVERY:
- Écrivez tout ce qui fait plus d'une ligne dans .tmp/scratch/reports/<YYYYMMDD>-<slug>.md et renvoyez le chemin.

CONTEXT:
- Location : <où chercher>
- Scope : <limites>
- Constraints : <exigences imposées par l'utilisateur ; modèles existants à suivre>
- Commands : <les portes de qualité du projet pour valider/tester, ou « découvrir celles que ce projet définit »>

ECOSYSTEM CONTEXT : (omettez la section si vide)
- <faits de session que l'agent ne peut pas lire ailleurs : CLI authentifiées, PR en cours de revue, autre agent actif sur les mêmes fichiers>

YOUR TASK :
<la ligne du tableau ci-dessous pour la phase, textuellement>

Lignes de phase pour YOUR TASK :

Phase	Ligne
read	Localisez et lisez le matériel dont dépend ce travail. Écrivez les chemins exacts et le contenu cité dans le fichier de livraison ; ne résumez pas les détails dont une phase ultérieure aurait besoin. Ne modifiez rien.
gather	Collectez les faits externes nommés dans CONTEXT. Enregistrez chacun avec sa source dans le fichier de livraison. Ne modifiez rien.
process	Analysez le matériel aux chemins indiqués dans OBSERVATIONS. Choisissez une approche ; enregistrez-la et pourquoi les alternatives ont été écartées. Ne modifiez rien.
verify	Vérifiez l'approche choisie par rapport au code réel et à l'environnement dans CONTEXT. Enregistrez où elle fonctionne et où elle échoue. N'implémentez rien.
write	Effectuez la modification dans DEFINITION OF SUCCESS. Ne touchez que les fichiers dans le Scope de CONTEXT.
validate	Exécutez les commandes dans CONTEXT Commands, ou découvrez les portes de lint/type/compilation de ce projet et indiquez lesquelles vous avez exécutées. Rapportez la sortie exacte, succès et échec. Un échec silencieux est un échec.
test	Exécutez l'invocation de test dans CONTEXT Commands, ou découvrez-la et indiquez laquelle vous avez exécutée. Ajoutez des tests couvrant la modification. Rapportez la sortie exacte.
report	Indiquez ce qui a changé et les preuves : fichiers, commandes, sorties. Ne faites aucune affirmation que les preuves ne soutiennent pas.
review	Critiquez le résultat au chemin dans OBSERVATIONS par rapport à DEFINITION OF SUCCESS. Rapportez les lacunes, contradictions, affirmations non étayées. Ne corrigez rien.

Règles pour le remplir :

• Une section que vous ne pouvez pas remplir à partir de ce qui est déjà dans votre contexte est omise, pas inventée. OBSERVATIONS ou ECOSYSTEM CONTEXT vides sont un état valide ; une supposition ne l'est pas.
• OBSERVATIONS est un passage direct : uniquement ce qui est déjà dans votre contexte. Lire, grepper ou exécuter des commandes pour le remplir est un pré-collecte ; l'agent le fait avec une fenêtre fraîche.
• Énoncez les observations comme des faits (« code de sortie 1 », « le texte d'erreur est : … »). Si vous avez une hypothèse, étiquetez-la : Hypothèse à vérifier : ….
• Constraints sont des résultats et des limites, jamais des étapes. Nommer la propre porte du projet dans Commands est une contrainte, pas une étape.
• Ne dites rien que l'agent hérite : conventions du dépôt, chaîne d'outils, « explorez librement », « utilisez les compétences disponibles ». Cela vit dans les instructions de l'agent pour le projet. Ne nommez une compétence que lorsque l'agent doit la charger et ne le ferait pas tout seul.
• Chemins : écrits comme l'agent les résoudra depuis son propre répertoire de travail ; relatifs dans le dépôt, et la forme de lien symbolique (pas la cible résolue) pour tout ce qui est atteint via un lien symbolique.

Prompt — mode générique

PHASE: <write | validate | test | read>
TASK: <l'instruction exacte — la modification à faire, le motif à trouver, la commande à exécuter>

FILES:
- <chemins exacts>

DEFINITION OF SUCCESS:
- <la commande de vérification et son résultat attendu>

DELIVERY:
- Incluez la sortie de vérification dans votre rapport.

Arbitrer

Les rapports sont des affirmations. Pour chacun :

• Vérifiez que la preuve soutient la conclusion. « Les tests passent » sans la sortie de la commande n'est pas une preuve ; renvoyez pour obtenir la sortie.
• Jugez le travail retourné ; ne le redérivez pas. Re-lire ce que l'agent a lu dépense le contexte que la délégation a économisé.
• Deux rapports sont en conflit → trouvez l'affirmation falsifiable et envoyez une vérification pour celle-ci. La confiance n'est pas un critère de départage.
• PARTIAL → renvoyez le reste, en nommant exactement ce qui reste.
• BLOCKED sur une entrée manquante → fournissez-la et renvoyez. BLOCKED après des tentatives → changez d'approche ou escaladez vers l'utilisateur ; ne renvoyez pas le même prompt.

Renvoi de la même phase au maximum deux fois sur le même écart. Après cela, arrêtez-vous et rapportez BLOCKED à l'utilisateur en nommant l'écart.

Toute demande qui a modifié du code reçoit une revue indépendante, d'un réviseur autre que l'auteur.

Extension de motif

Un utilisateur pointant vers une instance d'une odeur de code, d'un bogue ou d'une vérification manquante nomme un motif. Sauf s'il a dit « seulement celui-ci » : envoyez un audit du fichier ou du module entier pour le motif, rapportez les instances trouvées et confirmez avec l'utilisateur avant de corriger au-delà du fichier nommé.

Pointeurs

• references/sub-agent-contract.md — ce que suivent les agents envoyés.
• references/fix-cycle.md — le cycle de reproduction d'abord pour les envois de correction de bogue.
• parallel-work — éventail, convergence, producteur/vérificateur, tournois, boucles avec plafonds ; pointe également vers les mécanismes du harnais Claude Code.
• Si orchestrator-discipline est installé : ce que l'orchestrateur peut lire et exécuter ; appliqué par des crochets.
• Si process-siren est installé : écrire les points de décision sous forme de losanges Mermaid évaluables.