Quatre idées, une par écran. Chacune est un point d'appui pendant que vous expliquez. Tout se joue dans le regard, alors laissez les silences.
Quatre étapes : comprendre ce qu'est un subagent, en créer un, bien le concevoir, puis juger quand y recourir.
/agentsIl reçoit un rôle et une tâche, fait le travail ingrat hors de votre vue, et ne rend que la réponse.
Déjà intégrés : un agent general-purpose , Explore pour la recherche rapide, et Plan pour la recherche en mode plan. La contrepartie : vous perdez de vue comment il y est arrivé.
/agents : Claude écrit le fichierDécrivez ce que vous voulez ; Claude génère le nom, la description et le system prompt. C'est un fichier markdown avec un court en-tête YAML.
Choisissez sa portée au niveau du projet (ce dépôt) ou au niveau de l'utilisateur (partout). Mettez le mot « proactively » dans la description et Claude déléguera sans qu'on le lui demande.
Un bon subagent est guidé par sa description, sait quand s'arrêter, signale ce qu'il a rencontré, et ne touche que le strict nécessaire.
La description joue double jeu : elle décide quand le subagent se lance et façonne le prompt de tâche que l'agent principal lui écrit. Flou en entrée, flou en sortie.
Cette seule question tranche. Si vous n'avez pas besoin de suivre le parcours, déléguez. Si vous en avez besoin, gardez-le dans votre fil principal.
Pourquoi la revue de code figure ici : Claude critique mieux un code qu'il n'a pas écrit. Un relecteur au contexte neuf vaut mieux que le fil qui a construit la fonctionnalité.
Un subagent tourne dans son propre contexte et renvoie un résumé. Créez-le avec /agents, pilotez-le avec une description précise et un format de sortie, et n'y recourez que lorsque le chemin parcouru n'a pas d'importance.
tutto.one/praxis · daniel@tutto.one