Agents spécialisés et hooks : la spécialisation et le réflexe

Pourquoi spécialiser les agents

Un agent généraliste avec 30 pages de contexte fait tout moyennement. Le projet étudié définit 5 agents spécialisés (.claude/agents/*.md) — chacun un prompt système ciblé, des outils restreints, une mission :

• arch-guard : vérifie qu'un changement respecte les frontières (modules étanches, Protocols, pas d'import croisé) — le relecteur d'architecture ;
• mr-review : la revue de MR selon LES critères de l'équipe (invariants du manifeste, tests présents, conventions) ;
• test-gap-finder : cherche ce qui n'est PAS testé — l'adversaire de la couverture de façade ;
• doc-keeper : détecte les docs/ADRs rendus mensongers par un changement ;
• matching-debugger : l'enquêteur du pipeline (scores, candidats, cache history).

Deux vertus de la spécialisation : un contexte court et pointu (l'agent de revue n'a pas besoin de savoir déployer), et des outils bornés (l'agent de lecture n'a pas le droit d'écrire — le moindre privilège, appliqué aux agents).

Les hooks : le réflexe avant la réflexion

Les agents lisent le manifeste… mais un garde-fou qui dépend de la lecture n'est pas un garde-fou. Les hooks sont des scripts déclenchés automatiquement autour des actions de l'agent (avant un commit, avant l'exécution d'un outil). Celui du projet (check-before-commit.sh, branché en PreToolUse) bloque physiquement quatre interdits :

1. commit sur main ;
2. WHERE tenant_id manuel (l'invariant RLS !) ;
3. littéral de schéma en dur ;
4. lien mort dans les docs.

La philosophie : les interdits critiques ne se négocient pas en prompt, ils se codent en hook. Le prompt oriente (probabiliste) ; le hook interdit (déterministe). Tout invariant dont la violation coûte cher mérite de passer du manifeste au hook — le manifeste explique, le hook applique.