Chapitre 8.4 — Atelier : déléguer sur TaskFlow

⏱️ TL;DR — On applique la délégation sur TaskFlow avec deux usages canoniques : une exploration (Explore) qui cartographie un aspect du code sans polluer la session, et une revue indépendante du CRUD des tâches par un agent au regard neuf. On en profite pour définir un agent sur-mesure (.claude/agents/reviewer.md) réutilisable. Et on garde la règle d’or : on délègue l’exploration et le regard, on garde la décision.

🎯 Objectifs

Déléguer une exploration ciblée (Explore) et en exploiter la synthèse.
Obtenir une revue indépendante d’une feature.
Définir un agent sur-mesure réutilisable.
Garder la décision au centre.

Délégation 1 — l’exploration

Question : « comment TaskFlow gère-t-il les erreurs aujourd’hui ? » — beaucoup de lecture pour une conclusion courte : cas d’école (8.2). On délègue à Explore :


Explore : « Cartographie la gestion des erreurs dans TaskFlow.
Où sont levées/attrapées les erreurs (server actions, queries, UI) ?
Y a-t-il un pattern cohérent ? Renvoie : les fichiers clés, le flux, et
les incohérences éventuelles. Ne colle pas le code entier. »

Le subagent lit ce qu’il faut dans son contexte, et te renvoie une synthèse : « les actions valident via Zod et renvoient des erreurs typées ; mais queries.ts laisse fuir les erreurs Prisma brutes — incohérence ». Ta session principale n’a pas été noyée par la lecture ; tu as le signal, prêt à décider (« harmonisons la gestion d’erreur des queries »).

💡 Réflexe d’architecte — Après une exploration déléguée, tu décides, tu ne laisses pas le subagent « corriger dans son coin ». Il a ramené la carte ; le geste correctif se pilote au centre, avec ta vue d’ensemble et le cadre (P3/P4). Explorer ≠ agir.

Délégation 2 — la revue indépendante

Le CRUD des tâches (5.5) a été écrit dans une session ; le faire relire par un agent au contexte neuf attrape ce que l’auteur (agent ou toi) ne voit plus — c’est le principe du regard indépendant (8.2).


« Lance un subagent de revue sur src/features/tasks/. Objectif : trouver les
vrais problèmes de correction et les écarts par rapport à nos conventions
(CLAUDE.md). Pour chaque finding : fichier:ligne, le problème, la gravité.
N'invente pas de findings ; si tout est bon, dis-le. »

Tu récupères une liste actionnable, produite sans le biais « je viens de l’écrire, ça me semble bien ». C’est un avant-goût de la Partie 11 (/code-review, qui industrialise ça).

Définir un agent sur-mesure réutilisable

Si tu délègues souvent une revue, formalise un agent sur-mesure dans .claude/agents/reviewer.md (niveau projet, versionné) : un rôle avec son prompt et ses outils. Forme typique :


---
name: reviewer
description: Relecteur TaskFlow — correction + respect des conventions
tools: Read, Grep, Glob
---
 
Tu es un relecteur exigeant de TaskFlow. Vérifie :
1. Correction (bugs, cas d'erreur/vide manquants, revalidation après mutation).
2. Respect du CLAUDE.md (no-any, server actions, tokens, UI depuis @/components/ui,
   validation Zod partagée).
Pour chaque finding : `fichier:ligne` — problème — gravité (bloquant/mineur).
N'invente rien. Si c'est propre, dis-le. Ne modifie aucun fichier (lecture seule).

Avantages : le rôle est cohérent (mêmes critères à chaque revue), versionné (toute l’équipe/tout agent l’utilise), et lecture seule (aucun risque). Tu l’invoques quand tu veux un regard sur une feature.

Un mot sur le parallèle

Si tu voulais, avant une release, explorer trois aspects indépendants de TaskFlow (erreurs, perf des queries, accessibilité de l’UI), tu lancerais trois subagents en parallèle (8.2) — chacun sa synthèse, temps total ≈ le plus lent. Mais pour l’atelier du jour, deux délégations ciblées suffisent : inutile de sur-orchestrer.

⚠️ Piège — Enchaîner les délégations au point de ne plus rien faire toi-même dans la session principale. Déléguer, ce n’est pas se décharger de la conduite : tu restes le pilote qui reçoit les synthèses, arbitre, et lance les corrections. Trop de subagents = une session principale réduite à un standard téléphonique.

🧭 Sur TaskFlow — On a maintenant un agent reviewer réutilisable et le réflexe de déléguer l’exploration. C’est la base sur laquelle la Partie 11 va construire une vraie boucle de revue (/code-review, /diagnose). Le fil rouge sait déjà : automatiser sa qualité (P7) et déléguer ses regards (P8).

✏️ Exercices

Exercice 1 — Explore + décision. Sur un projet, délègue à Explore une question « beaucoup de lecture → peu de conclusion ». Reçois la synthèse, puis décide de l’action toi-même (ne laisse pas le subagent corriger). Ta session est-elle restée nette ?

✅ Solution

Bien fait, ta session principale n’a pas absorbé la lecture (elle est chez le subagent), et tu tiens une conclusion actionnable. Tu pilotes ensuite la correction avec ta vue d’ensemble. Si tu as laissé le subagent modifier, tu perds le contrôle du cadre — préfère « il explore, je décide ».

Exercice 2 — Un agent reviewer. Définis un agent reviewer en lecture seule dans .claude/agents/. Lance-le sur une de tes features. Ses findings sont-ils actionnables (fichier:ligne + gravité) ?

✅ Solution

Un bon reviewer renvoie des findings précis et gravés, sans inventer, en lecture seule. Formalisé, il donne des revues cohérentes et réutilisables — le socle de la boucle qualité (P11). S’il invente ou modifie, resserre son prompt (« n’invente rien », « lecture seule »).

🧠 Quiz de révision

1. Pourquoi déléguer l’exploration de la gestion d’erreur ?

Parce que c’est « beaucoup de lecture pour peu de conclusion » : on isole le bruit dans le subagent et on récupère juste la synthèse, gardant la session principale nette.

2. Quel est l’intérêt d’une revue par un agent au contexte neuf ?

Un regard indépendant, non biaisé par « je viens de l’écrire ». Il attrape des problèmes que l’auteur (agent ou toi) ne voit plus. C’est l’avant-goût de /code-review (P11).

3. Où et comment définir un agent sur-mesure ?

Dans .claude/agents/<nom>.md (projet, versionné) : un front-matter (nom, description, outils) + un prompt système décrivant le rôle et le format de sortie. Ex. un reviewer en lecture seule.

4. Après une exploration déléguée, qui décide de la correction ?

Toi (au centre, avec la vue d’ensemble et le cadre). Le subagent a ramené la carte ; on ne le laisse pas « corriger dans son coin ». Explorer ≠ agir.

5. Quel est le risque de trop déléguer dans une session ?

Réduire la session principale à un standard téléphonique : tu ne fais plus rien toi-même, tu ne fais que router. Déléguer, c’est isoler/paralléliser ce qui le mérite, pas se décharger de la conduite.

Fin de la Partie 8. Tu sais déléguer proprement. On aborde maintenant l’extension la plus riche : Partie 9 — Étendre Claude Code : les Skills.