Agents & sous-agents

Un sous-agent est une instance de Claude Code lancée avec sa propre fenêtre de contexte, éventuellement un prompt système spécialisé et un sous-ensemble d'outils. On délègue à un sous-agent pour :

• Protéger le contexte principal : une recherche qui produirait beaucoup de bruit (lecture de dizaines de fichiers) reste dans le sous-agent ; seul le résumé final remonte à la conversation principale.
• Spécialiser le comportement : un agent "Explore" en lecture seule, un agent "code-reviewer" avec un prompt orienté qualité, etc.
• Paralléliser : plusieurs sous-agents indépendants peuvent travailler en même temps sur des sous-tâches distinctes.

Un sous-agent se définit dans .claude/agents/ :

---
name: code-reviewer
description: Relit un diff pour des bugs, des problèmes de sécurité et de la dette technique.
tools: Read, Grep, Glob, Bash
model: inherit
---
Tu es un relecteur de code exigeant. Pour chaque diff, identifie :
1. Les bugs probables et cas limites non gérés.
2. Les failles de sécurité (injection, XSS, secrets en dur).
3. Les opportunités de simplification, sans sur-ingénierie.

On l'invoque ensuite via l'outil Task/Agent (subagent_type: "code-reviewer"), ou indirectement via une commande comme /review.

Un sous-agent peut tourner :

• en avant-plan, bloquant la conversation jusqu'à son retour (utile quand son résultat est nécessaire pour continuer) ;
• en arrière-plan (run_in_background), pour du travail indépendant dont le résultat n'est pas immédiatement bloquant ;
• dans un worktree git isolé (isolation: "worktree"), pour travailler sur une copie du repo sans risquer le répertoire de travail principal.

Un nouvel appel d'agent démarre sans mémoire de la conversation en cours : tout le contexte nécessaire doit être inclus explicitement dans le prompt de délégation.

Un sous-agent ne voit que ce qu'on lui donne. Un bon prompt de délégation :

• explique l'objectif et pourquoi la tâche est nécessaire ;
• donne les chemins de fichiers, noms de fonctions, contraintes déjà identifiées ;
• précise le format de réponse attendu (court résumé, liste, etc.) ;
• évite de déléguer la compréhension : ne demandez pas « corrige le bug », mais détaillez ce que vous savez déjà du bug et ce qu'il reste à vérifier.

Une consigne vague produit un travail générique ; un brief précis produit un travail exploitable directement.