PodcastsHear the voice. See the shape of the thought.

Claude Code embarque des sous-agents natifs, mais les sous-agents personnalisés permettent de connecter un comportement spécialisé à des tâches précises. Ce tutoriel crée un sous-agent de révision de code de zéro — en parcourant la commande `/agents`, le choix des outils, le choix du modèle et les champs de configuration qui contrôlent quand et comment Claude délègue. ## [00:03] Ce que sont les sous-agents personnalisés Claude Code inclut des sous-agents natifs, mais vous pouvez aussi créer les vôtres, spécialisés dans des tâches particulières. Un sous-agent personnalisé est un fichier Markdown avec un front matter YAML : le front matter indique à Claude quand router vers cet agent et quelles capacités il possède, tandis que le corps Markdown constitue le prompt système sous lequel le sous-agent s'exécute. > *"Custom sub aents are markdown files with YAML front matter. These markdown files contain configuration that helps claude understand when to use the sub aent and provides directions to the sub aent itself."* ## [00:28] Créer un sous-agent avec /agents La commande `/agents` ouvre le panneau de gestion des agents. En sélectionnant « Créer un nouvel agent », deux questions sont posées : la portée (projet courant ou partagé sur tous les projets de la machine) et la méthode de génération. La voie recommandée est de laisser Claude générer automatiquement l'agent — dans le tutoriel, le narrateur saisit en langage naturel une demande de sous-agent chargé de réviser la qualité du code et les problèmes de sécurité, et Claude s'occupe du reste. > *"Now, the easiest way to create a sub agent is with the / agents command. Next, you can create a sub agent manually, but we recommend using claw code to automatically generate it for you."* ## [00:56] Configurer outils, modèle et couleur Avant que Claude génère le fichier, vous choisissez les outils auxquels le sous-agent peut accéder. Un agent de révision de code n'a pas strictement besoin des outils d'édition, mais laisser l'exécution activée lui permet d'inspecter plus facilement les modifications en attente. Après les outils, on choisit le modèle : haiku pour la vitesse, opus pour la profondeur d'analyse, sonnet pour un équilibre entre les deux. Dernier choix, une couleur qui apparaît dans l'interface pour repérer le sous-agent en un coup d'œil. > *"Now, given that our sub agent is only responsible for reviewing code, you might decide to disallow tools for editing, but I'll leave an execution to allow the sub agent to more easily identify pending changes."* ## [01:43] Comprendre le fichier de configuration Le fichier généré est enregistré dans le projet à l'emplacement affiché dans la fenêtre de résumé. Quatre champs sont essentiels. `name` est l'identifiant unique — vous pouvez l'invoquer en tapant `@agent-code-quality-reviewer` dans un message. `description` est ce que Claude lit pour décider de déléguer ; elle doit tenir sur une seule ligne (les caractères `\n` échappés sont littéraux). Ajouter « proactively » dans la description incite Claude à recourir plus souvent à l'agent ; des exemples de conversations rendent le routage plus précis. `tools` reflète les accès accordés lors de la génération, mais peut être édité directement dans le fichier. > *"If you want Claude to use the sub agent automatically more often, add in the word proactively to the description."* ## [02:41] Le prompt système et son utilisation par Claude Le champ `model` accepte `haiku`, `sonnet`, `opus` ou `inherit` — `inherit` fait tourner le sous-agent sur le même modèle que la conversation parente. Tout ce qui suit le front matter constitue le prompt système : il guide le sous-agent dans sa tâche et lui indique comment rendre les résultats à l'agent principal. > *"The system prompt will provide guidance to the sub agent, helping it understand how to complete its task and how it should return information back to the main agent."* ## [03:15] Tester votre sous-agent Une fois la configuration enregistrée, effectuez quelques modifications de code et demandez à Claude de les réviser. Si le sous-agent ne se déclenche pas au moment attendu, le champ `description` est le premier endroit à ajuster — des exemples plus précis affinent la compréhension de Claude quant au moment de déléguer. > *"If the sub agent isn't being used when you expect, check your description. Adding more specific examples helps Claude understand when to delegate."* ## Entités - **Anthropic Tutorial Narrator** (Personne) : seul présentateur de cet épisode ; anime la série de tutoriels Claude Code subagents sur la chaîne YouTube officielle d'Anthropic - **Claude Code** (Logiciel) : assistant de codage IA d'Anthropic ; prend en charge les sous-agents natifs et les sous-agents personnalisés créés par l'utilisateur - **Custom subagent** (Concept) : fichier Markdown avec front matter YAML qui configure Claude Code pour déléguer des tâches spécifiques à une instance d'agent spécialisé - **/agents command** (Concept) : point d'entrée UI de Claude Code pour créer et gérer les sous-agents ; portée projet ou globale - **System prompt** (Concept) : corps Markdown du fichier de configuration d'un sous-agent ; fournit au sous-agent ses instructions de tâche et de format de sortie à l'exécution - **Anthropic** (Organisation) : créateur de Claude et de la plateforme Claude Code

Ce tutoriel de la série Claude Code d'Anthropic présente quatre patterns concrets qui distinguent les sous-agents fiables de ceux qui dérivent, se bloquent ou modifient des fichiers qu'ils ne devraient pas toucher. Le narrateur passe en revue chaque pattern avec un sous-agent de revue de code et un sous-agent de recherche web comme exemples fil rouge, en montrant précisément quels paramètres ajuster et pourquoi. ## [00:03] Contrôler le comportement du sous-agent via le nom et la description Chaque message envoyé à l'agent principal inclut le nom et la description de chaque sous-agent enregistré dans le prompt système. La description remplit donc deux fonctions : indiquer à l'orchestrateur *quand* lancer le sous-agent, et fournir le modèle qu'il utilise pour rédiger le prompt d'entrée. Le tutoriel illustre cela avec un sous-agent de revue de code. Dans la configuration d'origine, l'orchestrateur rédige un prompt générique qui demande au sous-agent d'appeler lui-même `git diff`. En modifiant la description pour préciser « vous devez indiquer à l'agent exactement quels fichiers vous voulez qu'il examine », la sélection des fichiers devient la responsabilité de l'orchestrateur — la prochaine exécution produit un prompt d'entrée nettement plus spécifique. Le même levier fonctionne avec les sous-agents de recherche web : ajouter « renvoyer des sources citables » à la description amène le fil principal à inclure automatiquement cette instruction lors de chaque délégation. > *"If you want to better control when the main agent launches a sub agent automatically, you should modify the name and description."* ## [01:41] Définir le format de sortie Le narrateur identifie le format de sortie comme l'amélioration la plus impactante disponible. Sans format défini, un sous-agent n'a pas de signal clair pour savoir quand il en a fait assez — il continue à tourner, accumule du contexte et consomme des tokens inutilement. Un format de sortie structuré crée un point d'arrêt naturel : dès que les champs obligatoires sont remplis, le sous-agent sait qu'il a terminé. Concrètement, cela revient à ajouter un schéma explicite — bloc de résumé, liste de résultats, champ de statut — directement dans le prompt système du sous-agent. > *"Without a defined output format, sub agents struggle to decide when enough research has been done and they tend to run much much longer than sub agents that are given an output format."* ## [02:04] Signaler les obstacles dans le résumé Quand un sous-agent résout un problème — un conflit de dépendances, une commande nécessitant des flags inattendus, une particularité d'environnement — le fil principal doit disposer de cette information, sinon il se heurtera au même obstacle à l'étape suivante. La solution consiste à exiger le signalement des obstacles dans le format de sortie lui-même. Le narrateur liste les catégories qui doivent toujours remonter : obstacles rencontrés, problèmes d'installation, contournements trouvés, commandes ayant nécessité des flags ou une configuration particulière, et dépendances ou imports ayant posé problème. Les intégrer dans le schéma de sortie obligatoire permet au fil principal d'hériter des découvertes du sous-agent plutôt que de les retrouver par lui-même. > *"Otherwise, the main thread has to rediscover the same solutions, obstacles encountered, any setup issues, workarounds discovered or environment quirks, commands that needed special flags or configuration, dependencies or imports that cause problems."* ## [02:42] Limiter l'accès aux outils par rôle L'accès aux outils n'est pas seulement un contrôle de sécurité — c'est aussi un outil de clarté. Un sous-agent en lecture seule disposant uniquement de `glob`, `grep` et `read` ne peut pas accidentellement modifier des fichiers, ce qui rend son rôle sans ambiguïté pour quiconque lit la configuration. Le narrateur associe trois niveaux d'accès à trois rôles de sous-agent : un sous-agent de recherche n'a besoin que de l'accès en lecture, car explorer le code ne nécessite pas d'écriture ; un sous-agent de revue obtient `bash` pour `git diff` mais toujours pas d'outils d'édition ; seuls les sous-agents explicitement chargés de modifier le code — comme un sous-agent appliquant des mises à jour CSS — reçoivent `edit` et `write`. Avec plusieurs sous-agents en jeu, la liste d'outils devient un résumé lisible par machine de ce que chacun est censé faire. > *"Only give edit and write to sub agents that should actually change your code, like a styling agent applying CSS updates."* ## [03:27] Les quatre patterns d'un sous-agent efficace Le tutoriel se conclut par un récapitulatif en une phrase des quatre patterns : sortie structurée, signalement des obstacles, descriptions précises et accès aux outils restreint. Chaque pattern renforce les autres — les descriptions précises réduisent l'ambiguïté des prompts d'entrée, les formats de sortie créent des points d'arrêt, le signalement des obstacles préserve le contexte entre les frontières d'agents, et l'accès minimal aux outils prévient les effets de bord qui aggraveraient l'ambiguïté résiduelle. > *"So effective sub agents use structured output report obstacles have specific descriptions and limit tool access."* ## Entités - **Anthropic Tutorial Narrator** (Personne) : animateur de la série de tutoriels Claude Code subagents, intervenant au nom d'Anthropic - **Claude Code** (Logiciel) : outil de codage agentique d'Anthropic qui orchestre des sous-agents pour accomplir des tâches d'ingénierie en plusieurs étapes - **Subagent** (Concept) : instance Claude spécialisée lancée par un agent orchestrateur, dotée de son propre prompt système, de ses accès aux outils et de son prompt d'entrée - **Format de sortie** (Concept) : schéma obligatoire défini dans le prompt système d'un sous-agent, créant une condition d'arrêt et structurant les informations renvoyées au fil principal - **Signalement des obstacles** (Concept) : pattern consistant à exiger des sous-agents qu'ils remontent contournements, problèmes de dépendances et particularités d'environnement dans leur sortie, afin que l'orchestrateur n'ait pas à les redécouvrir - **Restriction de l'accès aux outils** (Concept) : limitation de chaque sous-agent aux seuls outils requis par son rôle — lecture seule pour la recherche, bash pour la revue, edit/write uniquement pour les agents devant modifier des fichiers - **Anthropic** (Organisation) : créateur de Claude et de la plateforme de codage agentique Claude Code

Les sous-agents sont des assistants spécialisés auxquels Claude Code peut déléguer des tâches — chacun s'exécute dans sa propre fenêtre de contexte isolée, accomplit son travail de façon autonome, puis renvoie un résumé ciblé pendant que toute la trace intermédiaire est effacée. Ce tutoriel de deux minutes produit par Anthropic explique pourquoi cet isolement est essentiel pour maintenir la fenêtre de contexte principale utilisable, illustre le compromis via un scénario d'exploration de code, et liste les sous-agents intégrés fournis avec Claude Code. ## [00:03] Ce que sont les sous-agents Un sous-agent s'exécute dans sa propre fenêtre de contexte de conversation, initialisée avec un system prompt personnalisé que vous définissez. L'agent parent (Claude Code dans le fil principal) lui confie une description de tâche basée sur votre demande. Le sous-agent l'exécute de façon autonome, puis renvoie un résumé au fil principal — tout le travail intermédiaire reste isolé. > *"Sub-agents are specialized assistants that Claude can delegate tasks to."* Point de conception essentiel : une fois le sous-agent terminé, l'intégralité de son fil de conversation est définitivement effacée. Seul le résumé renvoyé subsiste dans la conversation principale. ## [00:24] Gérer la fenêtre de contexte Chaque appel d'outil effectué par Claude dans le fil principal — lectures de fichiers, recherches, traces de fonctions — s'accumule dans la fenêtre de contexte principale. Sur une longue session, elle se remplit rapidement. Les sous-agents existent précisément pour délester les tâches de recherche ou d'action discrètes, sans que ce coût ne s'impute sur la fenêtre principale. > *"Each sub-agent runs in its own conversation contacts window with a custom system prompt that you define."* Le compromis est explicite : la fenêtre principale gagne un contexte propre, mais perd toute visibilité sur la façon dont le sous-agent est parvenu à ses conclusions et ce qu'il a découvert en chemin. Vous obtenez la réponse, pas la trace du raisonnement. ## [01:13] Un exemple concret : le système de paiement Imaginez que vous utilisez Claude Code pour identifier quel service gère les remboursements dans une base de code inconnue. Sans sous-agent, Claude pourrait lire 15 fichiers, lancer plusieurs recherches et parcourir de nombreux appels de fonctions — tout cela remplirait la fenêtre de contexte principale alors que vous n'aviez besoin que d'un seul fait. > *"With a sub-agent, you get the answer without the journey."* Le sous-agent explore la base de code, trouve la réponse et renvoie un résumé ciblé — en gardant votre contexte principal propre. La visibilité perdue en est le prix : vous ne verrez pas quels fichiers il a lus ni quelles traces il a suivies pour y parvenir. ## [02:00] Les sous-agents intégrés de Claude Code Claude Code est livré avec trois sous-agents intégrés, prêts à l'emploi : - **Sous-agent général** — pour les tâches en plusieurs étapes nécessitant à la fois exploration et action. - **Sous-agent Explore** — recherche rapide dans les bases de code, sans la surcharge d'une boucle de tâche complète. - **Sous-agent Plan** — s'exécute en mode plan pour analyser la base de code avant de vous présenter un plan. > *"And you can also create your own sub-agents with custom system prompts and tool access."* Au-delà de ces trois sous-agents, vous pouvez définir des sous-agents personnalisés avec leurs propres system prompts et listes d'accès aux outils, adaptés à des workflows spécifiques. ## [02:30] Quand utiliser les sous-agents Les sous-agents sont utiles dès que vous avez une question ou une tâche discrète et autonome qui, autrement, déverserait beaucoup de contexte intermédiaire dans votre fenêtre principale. > *"Sub-agents like Claude Code break work into focused pieces, keep your main context window clean, and bring back just what you need, whether you're using the built-in ones or creating your own."* Ils sont particulièrement précieux lors de longues sessions Claude Code où la pression sur la fenêtre de contexte s'accumule — déléguer une sous-tâche à un sous-agent plutôt que de la laisser se déployer dans le fil principal prolonge directement la durée effective d'une session. ## Entités - **Anthropic Tutorial Narrator** (Personne) : narrateur de la série de tutoriels "Claude Code subagents" produite par Anthropic - **Claude Code** (Logiciel) : assistant de codage agentique d'Anthropic ; l'environnement hôte dans lequel les sous-agents opèrent - **Claude** (Logiciel) : le modèle d'IA sous-jacent qui propulse Claude Code et ses sous-agents - **Sous-agent** (Concept) : assistant spécialisé auquel Claude Code délègue des tâches, s'exécutant dans une fenêtre de contexte isolée avec son propre system prompt - **Fenêtre de contexte** (Concept) : le tampon de tokens fini contenant tout l'historique de conversation, les appels d'outils et leurs résultats ; les sous-agents empêchent qu'il se remplisse de travail intermédiaire - **Sous-agent général** (Logiciel) : sous-agent intégré de Claude Code pour les tâches d'exploration et d'action en plusieurs étapes - **Sous-agent Explore** (Logiciel) : sous-agent intégré de Claude Code optimisé pour la recherche rapide dans les bases de code - **Sous-agent Plan** (Logiciel) : sous-agent intégré de Claude Code qui analyse la base de code en mode plan avant de présenter un plan - **Anthropic** (Organisation) : créateur de Claude et Claude Code ; producteur de cette série de tutoriels

Les skills Claude Code sont des fichiers Markdown réutilisables qui encodent une connaissance spécialisée une seule fois — Claude les active ensuite automatiquement dès qu'une requête correspond, sans que l'utilisateur ait besoin de répéter des instructions ou de taper une commande slash. Ce tutoriel de trois minutes explique ce que sont les skills, où ils résident, en quoi ils diffèrent des fichiers CLAUDE.md, et quel signal indique qu'il est temps d'en écrire un. ## [00:03] Le problème de répétition que les skills résolvent Chaque fois que vous expliquez les normes de codage de votre équipe, que vous redécrivez le format souhaité pour les retours de PR, ou que vous rappelez à Claude votre format de commit préféré, vous vous répétez. Le narrateur enchaîne trois exemples pour nommer précisément le point de friction que les skills adressent. > *"Every time you explain your team's coding standards to Claude, you're repeating yourself."* ## [00:20] Ce qu'est un skill et comment Claude en sélectionne un Un skill est un fichier Markdown qui apprend à Claude comment faire quelque chose, une fois pour toutes. Claude retient l'instruction, puis l'applique automatiquement dès que la situation le requiert. Dans Claude Code, ce fichier s'appelle SKILL.md. Le champ description à l'intérieur est le mécanisme clé : quand vous demandez à Claude de revoir une PR, il compare votre requête à toutes les descriptions de skills disponibles et active celle qui correspond. > *"Claude reads your request, compares it to all available skill descriptions, and activates the ones that match."* ## [01:05] Où stocker les skills : personnel ou projet Les skills ont deux emplacements selon qui doit en bénéficier. Les skills personnels vont dans `~/.claude/skills` et vous suivent d'un projet à l'autre : style de commit, format de documentation, manière dont vous aimez qu'on vous explique le code. Les skills de projet vont dans `.claude/skills` à la racine du dépôt ; quiconque clone le dépôt les obtient automatiquement. C'est là que vivent les standards d'équipe : charte graphique, polices et couleurs pour le web design. > *"Anyone who clones the repository gets these skills automatically."* ## [01:42] Skills vs CLAUDE.md : déclenchement automatique et efficacité du contexte Claude Code propose plusieurs couches de personnalisation, et les skills occupent une niche bien distincte. Les fichiers CLAUDE.md se chargent dans chaque conversation sans condition, idéaux pour des règles comme « toujours utiliser le mode strict TypeScript ». Les skills se chargent à la demande, uniquement quand ils correspondent à la requête en cours, et seuls le nom et la description entrent dans le contexte à ce stade. Le corps complet du skill ne se charge qu'une fois déclenché. La checklist de revue de PR n'encombre donc pas le contexte pendant un débogage ; elle n'est tirée que lorsque vous demandez explicitement une revue. Les commandes slash nécessitent une saisie manuelle ; les skills, non. > *"Skills are unique because they're automatic and task-specific."* ## [02:27] Quand écrire un skill Les skills fonctionnent le mieux pour une connaissance spécialisée liée à des tâches précises : les normes de revue de code de l'équipe, les formats de commit, les chartes graphiques. La règle finale est franche et pratique : si vous vous retrouvez à expliquer la même chose à Claude encore et encore, c'est un skill qui attend d'être écrit. > *"If you find yourself explaining the same thing to Claude repeatedly, well, that's a skill waiting to be written."* ## Entités - **Anthropic Tutorial Narrator** (Personne) : narrateur et animateur de la série de tutoriels Claude Code skills - **Claude Code** (Logiciel) : assistant de codage AI d'Anthropic ; l'environnement d'exécution où les skills sont découverts et appliqués - **SKILL.md** (Concept) : le fichier Markdown qui définit un skill — contient un nom, une description et des instructions pour Claude - **CLAUDE.md** (Concept) : fichier d'instructions au niveau du projet ou global qui se charge dans chaque conversation Claude Code sans condition, en contraste avec les skills - **Anthropic** (Organisation) : créateur de Claude et de Claude Code

Un skill de revue de PR utilisé par un seul ingénieur est utile ; le même skill déployé à l'échelle d'une équipe standardise la revue de code et garantit une expérience uniforme dans toute l'organisation. Ce tutoriel présente quatre méthodes de distribution concrètes — commits dans le dépôt, plugins, paramètres d'entreprise gérés et sous-agents personnalisés — en expliquant précisément quand chacune s'applique. La section sur les sous-agents contient un point non évident : les sous-agents n'héritent pas automatiquement des skills, et les agents intégrés n'y ont absolument pas accès. ## [00:01] Pourquoi le partage multiplie la valeur des skills Un skill qui reste chez un seul développeur remplit son rôle. Le même skill poussé à une équipe ancre des standards, élimine les variations individuelles et uniformise l'apparence et le ressenti de chaque revue. Le tutoriel s'ouvre sur un contraste direct entre usage individuel et usage à l'échelle d'une équipe, avant d'introduire les quatre mécanismes de partage. > *"A PR review skill that only you use is helpful. The same skill shared across your team standardizes code review and provides a consistent experience amongst your organization which is much better."* ## [00:18] Ajouter des skills à votre dépôt La méthode la plus simple : placer les skills dans `.claude/skills` au sein du dépôt du projet. Quiconque clone le dépôt les obtient immédiatement — aucune étape d'installation, aucun outil supplémentaire. Les mises à jour transitent par le cycle habituel de `git pull`. Cette approche convient aux standards de code d'équipe, aux workflows propres à un projet et aux skills qui référencent la structure du code. > *"Anyone who clones the repository gets these skills automatically. No extra installation, it's just what you're doing already."* ## [00:45] Distribuer des skills via des plugins Les plugins étendent Claude Code avec des fonctionnalités personnalisées conçues pour voyager au-delà d'un seul projet. Au sein du projet de plugin, un répertoire `skills/` reproduit la structure de `.claude/` — nom du skill, `SKILL.md`. Une fois publié sur un marketplace, n'importe quel utilisateur de Claude Code peut télécharger et activer le plugin. Ce canal est idéal pour les skills assez généraux pour servir la communauté au sens large plutôt que les conventions d'une seule équipe. > *"Think of plugins as ways to extend Claude Code with custom functionality, but designed to be shared across teams and projects."* ## [01:26] Déploiement à l'échelle de l'entreprise via les paramètres gérés Les administrateurs peuvent pousser des skills à chaque développeur de l'organisation via les paramètres gérés. Les skills d'entreprise ont la priorité la plus haute : ils écrasent les skills personnels, de projet et de plugin portant le même nom. L'usage prévu concerne les standards obligatoires — exigences de sécurité, workflows de conformité, pratiques de codage qui doivent être uniformes. Le narrateur insiste sur le mot « must » : ce ne sont pas des suggestions. > *"This is for mandatory standards, security requirements, compliance workflows, or coding practices that must be consistent across the organization."* ## [01:52] Sous-agents personnalisés et chargement explicite des skills Les sous-agents n'héritent pas des skills de la conversation principale. Les agents intégrés (explorer, planner, verify) ne peuvent pas accéder aux skills du tout. Seuls les sous-agents personnalisés — définis par un fichier `agent.md` dans `.claude/agents` — peuvent utiliser des skills, et uniquement ceux listés explicitement dans le champ `skills:` de ce fichier. Les skills se chargent au démarrage du sous-agent, pas à la demande, donc la liste doit rester concise : uniquement les skills toujours pertinents pour la mission de l'agent. Le tutoriel montre comment créer un sous-agent avec l'outil de création de sous-agents Claude Code et comment rattacher des skills à un `agent.md` existant. > *"Built-in agents like the explorer, planner, and verify can't access skills at all. Only custom sub-agents you define can use them, and only when you explicitly list them."* ## [03:18] Récap : choisir la bonne méthode de distribution La conclusion associe chaque méthode à son scénario : répertoires de projet pour l'accès en équipe, plugins pour le partage inter-dépôts, déploiement en entreprise pour les standards obligatoires à l'échelle de l'organisation, et listes de skills dans les sous-agents pour la délégation isolée de tâches. Le rappel sur les sous-agents revient une dernière fois — ne lister que les skills toujours pertinents pour un agent donné, car ils se chargent au démarrage, pas en différé. > *"Share skills through project directories for team access, plugins for cross-repository distribution, or enterprise deployment for organization-wide standards."* ## Entités - **Narrateur du tutoriel Anthropic** (Personne) : présentateur unique de la série de tutoriels Claude Code skills - **Claude Code** (Logiciel) : assistant de programmation IA d'Anthropic ; environnement d'exécution où les skills sont créés et déployés - **Skills** (Concept) : ensembles d'instructions réutilisables placés dans `.claude/skills` qui étendent le comportement de Claude Code - **Plugins** (Concept) : packages distribuables qui regroupent des skills pour les partager entre équipes et utilisateurs du marketplace - **Managed settings** (Concept) : mécanisme administrateur d'entreprise pour déployer des skills à l'échelle de l'organisation avec la priorité maximale - **Sub-agents** (Concept) : agents Claude Code personnalisés définis via `agent.md` dans `.claude/agents` ; seul type d'agent pouvant charger des skills, et uniquement quand ils sont explicitement listés - **Anthropic** (Organisation) : entreprise qui a créé Claude Code et produit la série de tutoriels Claude Code skills

Un tutoriel de quatre minutes issu de la série Claude Code skills, consacré aux champs de configuration avancés qui transforment un skill basique en outil fiable et économe en contexte. Le présentateur passe en revue l'ensemble des champs définis par agentskills.io — `name`, `description`, `allowed_tools`, `model` — puis explique comment structurer les skills de grande taille grâce à la divulgation progressive, afin que les ressources de référence et les scripts ne se chargent que lorsque la requête de l'utilisateur le nécessite réellement. ## [00:02] Panorama des champs avancés d'un skill Le standard ouvert agentskills.io définit plusieurs champs au-delà des obligatoires `name` et `description`. `name` doit être en minuscules avec des tirets, limité à 64 caractères et correspondre exactement au nom du répertoire. `description` peut aller jusqu'à 1 024 caractères et constitue le principal signal utilisé par Claude pour associer un skill à une requête. Deux champs optionnels complètent la configuration : `allowed_tools`, qui restreint les outils que le skill peut invoquer, et `model`, qui épingle le skill à une version précise de Claude. > *"Un skill basique fonctionne avec seulement un name et une description, mais voici quelques conseils avancés pour rendre vos skills vraiment efficaces dans Claude Code."* ## [00:39] Rédiger des descriptions efficaces Une description vague — « help with dogs » — laisse Claude deviner le périmètre et les conditions de déclenchement du skill. Une bonne description répond à exactement deux questions : que fait ce skill, et quand Claude doit-il l'utiliser ? Aligner les mots-clés sur la formulation naturelle des requêtes utilisateurs est le levier pour corriger les skills qui ne se déclenchent pas. > *"Une bonne description répond à deux questions : que fait ce skill ? Et quand Claude doit-il l'utiliser ?"* ## [01:20] Restreindre les outils avec allowed_tools `allowed_tools` est le mécanisme pour confiner un skill à une surface d'opération définie — accès en lecture seule pour les flux de travail sensibles, par exemple. Lorsque ce champ est renseigné, Claude ne peut appeler que ces outils sans demander de permission ; édition, écriture et Bash sont exclus. Omettre le champ laisse intact le modèle de permissions habituel de Claude. > *"Lorsque ce skill est actif, Claude ne peut utiliser que ces outils sans demander de permission. Ni édition, ni écriture, ni commandes bash."* ## [01:49] Divulgation progressive pour les skills multi-fichiers Les skills partagent la fenêtre de contexte de Claude avec la conversation en cours. Concentrer tout le contenu dans un `SKILL.md` de 20 000 lignes gonfle le contexte à chaque invocation et rend le fichier pénible à maintenir. La solution : placer les instructions essentielles dans `SKILL.md` et déplacer les ressources de référence dans des fichiers séparés, que Claude ne lit que lorsque la requête le justifie. Le standard recommande trois répertoires d'appui — `scripts/` pour le code exécutable, `references/` pour la documentation, `assets/` pour les images et les modèles. Un lien dans `SKILL.md` joue le rôle d'une entrée de table des matières ; si le sujet ne surgit pas, le fichier n'est jamais chargé. Les scripts du répertoire d'un skill s'exécutent sans que leur source soit chargée dans le contexte — seule leur sortie consomme des tokens. Le présentateur recommande de maintenir `SKILL.md` sous 500 lignes ; dépasser ce seuil est le signe qu'il faut découper le skill. > *"C'est comme avoir une table des matières dans la fenêtre de contexte plutôt que d'y faire tenir le document entier."* ## [03:18] Récapitulatif : métadonnées et bonnes pratiques Le tutoriel se conclut en rappelant l'ensemble des champs de configuration : `name` et `description` sont obligatoires ; `allowed_tools` restreint la surface d'outils ; `model` épingle la version de Claude. Les descriptions doivent contenir des verbes d'action précis et des formules de déclenchement pour matcher de manière fiable. Pour les skills de grande taille, la divulgation progressive maintient `SKILL.md` sous 500 lignes et reporte le chargement des fichiers d'appui jusqu'au moment où ils sont réellement nécessaires. Les scripts s'exécutent sans charger leur source, ce qui garde le contexte allégé. > *"Les scripts peuvent s'exécuter sans charger leur contenu, ce qui maintient le contexte efficace."* ## Entités - **Présentateur Anthropic** (Personne) : hôte unique de cette série de tutoriels, présentant la configuration des skills Claude Code. - **Claude Code** (Logiciel) : outil CLI d'Anthropic qui charge et exécute les skills conformément au standard agentskills.io. - **agentskills.io** (Organisation) : standard ouvert définissant le schéma du manifeste de skill, incluant `name`, `description`, `allowed_tools`, `model` et les conventions de répertoires. - **SKILL.md** (Concept) : fichier manifeste principal d'un skill Claude Code ; doit rester sous 500 lignes, avec des liens vers les fichiers d'appui. - **allowed_tools** (Concept) : champ optionnel du skill qui liste en liste blanche les outils Claude autorisés, permettant des modes skill en lecture seule ou en bac à sable. - **Divulgation progressive** (Concept) : structuration d'un skill multi-fichiers pour que les fichiers de référence et les scripts ne se chargent dans le contexte que lorsque la requête active le nécessite. - **Fenêtre de contexte** (Concept) : budget de tokens partagé entre la conversation et les fichiers de skill chargés par Claude ; la ressource clé que la divulgation progressive vise à préserver.

Ce tutoriel de 3 minutes explique comment construire une compétence Claude Code personnelle depuis le début : créer un répertoire contenant un fichier SKILL.md, vérifier que la compétence se charge au démarrage, puis observer Claude l'appliquer sur une vraie demande. La deuxième partie décrit précisément le pipeline de chargement des compétences — les quatre emplacements de scan, la passe de démarrage qui ne charge que les noms, la porte de confirmation, et l'ordre de priorité à quatre niveaux qui résout les conflits de noms. ## [00:03] Ce que ce tutoriel construit Le narrateur annonce d'emblée l'objectif concret : une compétence qui apprend à Claude à expliquer du code avec des diagrammes visuels et des analogies. Une fois la compétence construite, le tutoriel retrace ce qui se passe en interne quand Claude la détecte et l'exécute. > *"This skill will teach Claude how we would like it to explain code using visual diagrams and analogies."* ## [00:18] Création du fichier de compétence Les compétences personnelles se trouvent sous le répertoire personnel (pas dans un projet), donc la première étape consiste à créer un nouveau répertoire portant le nom de la compétence dans `~/.claude/skills/`. Ce répertoire contient un unique fichier SKILL.md. Trois sections sont essentielles : `name` (l'identifiant que Claude stocke au démarrage), `description` (le critère que Claude utilise pour décider d'invoquer la compétence) et tout ce qui suit le second délimiteur `---` (les instructions que Claude suit quand la compétence se déclenche). > *"Take into consideration that we're creating a directory with the skill name inside of the skills directory."* ## [00:52] Chargement et test de votre compétence Claude Code scanne les compétences au démarrage, pas à la demande, donc un redémarrage de session est nécessaire après la création du fichier. La commande `/skills` devrait alors lister la compétence nouvellement créée. Pour tester, on passe sur une branche avec des modifications et on envoie la demande en langage naturel « Write a PR description for my changes ». Claude indique qu'il invoque la compétence PR description, lit le diff et produit une description qui respecte le modèle, dans le même format à chaque fois. > *"Claude will then show you that it's using the PR description skill."* ## [01:25] Comment Claude charge les compétences en coulisses Au démarrage, Claude Code scanne quatre emplacements : les paramètres gérés par l'entreprise, le dossier personnel `~/.claude/skills/`, le répertoire `.claude/` du projet et les plugins installés. Il charge uniquement le `name` et la `description`, pas le contenu complet. Quand une demande arrive, Claude la compare aux descriptions stockées ; « explain what this function does » recoupe « explain code with visual diagrams », donc la compétence correspond. Claude demande ensuite une confirmation avant de lire le SKILL.md complet, afin que l'utilisateur sache toujours quel contexte est injecté. > *"It loads only the name and description of each skill, not the full content. This is important later."* ## [02:02] Règles de priorité et conflits de noms Cloner un dépôt qui embarque ses propres compétences peut créer des collisions de noms. Claude les résout avec une échelle de priorité fixe : entreprise (plus haute) → personnel → projet → plugins (plus basse). Une compétence `code-review` d'entreprise supplante toujours une compétence personnelle du même nom. La solution pratique est un nommage descriptif : `security-review` ou `frontend-pr-review` plutôt que le générique `review`, pour éviter les conflits dès le départ. > *"If your company has an enterprise code review skill and you create a personal code review skill, the enterprise version of that takes precedence."* ## [02:52] Mise à jour et suppression des compétences Mettre à jour une compétence revient à éditer directement le fichier SKILL.md et à sauvegarder. La supprimer, c'est supprimer le répertoire. Les deux opérations nécessitent un redémarrage de Claude Code pour prendre effet — la liste des compétences est construite une fois au démarrage de la session, sans surveillance des changements en temps réel. > *"Edit the skill.md file to update a skill and restart Claude Code for changes to take effect."* ## Entités - **Narrateur du tutoriel Anthropic** (Personne): animateur unique du tutoriel de création de compétences dans la série Claude Code skills - **Claude Code** (Logiciel): CLI d'Anthropic pour Claude ; scanne les compétences au démarrage et les applique quand les demandes correspondent aux descriptions - **SKILL.md** (Concept): l'unique fichier qui définit une compétence — contient un frontmatter YAML (name, description) et un texte d'instructions libre après le second délimiteur `---` - **Compétences** (Concept): ensembles d'instructions réutilisables et nommés qui enseignent à Claude un comportement cohérent ; stockés sous forme de répertoires contenant un fichier SKILL.md - **Compétences d'entreprise** (Concept): compétences gérées par l'organisation, au sommet de l'ordre de priorité à quatre niveaux, qui supplantent les compétences personnelles, de projet et de plugin - **Anthropic** (Organisation): créateur de Claude et Claude Code ; publie cette série de tutoriels sur claude.com/resources/courses

Claude Code offre aux développeurs cinq leviers de personnalisation distincts — Skills, CLAUDE.md, sous-agents, hooks et serveurs MCP — chacun conçu pour un usage précis. Ce tutoriel de trois minutes fait correspondre chaque option au bon cas d'usage, pour ne pas recourir aux Skills quand CLAUDE.md suffit, ni configurer un hook quand c'est un sous-agent qu'il faut. ## [00:02] Cinq options de personnalisation, un seul problème de choix Claude Code propose cinq façons de façonner son comportement : Skills, CLAUDE.md, sous-agents, hooks et serveurs MCP. Le narrateur les énumère rapidement, puis déplace aussitôt la question de « qu'est-ce que c'est ? » vers « lequel convient ici ? » > *"Ils résolvent des problèmes différents. Savoir quand utiliser chacun vous évite de construire la mauvaise chose."* Le reste du tutoriel n'est que l'élaboration de cette seule phrase. ## [00:18] CLAUDE.md vs Skills : permanent vs à la demande CLAUDE.md est un fichier que Claude lit au début de chaque conversation, sans activation requise. C'est l'endroit idéal pour les contraintes à l'échelle du projet qui ne doivent jamais être oubliées — choix de framework, style de code, règles de base de données. Les Skills, elles, se chargent à la demande : la checklist de revue de PR n'entre dans le contexte que lorsque vous demandez vraiment une revue, pas pendant que vous écrivez du nouveau code. > *"Use Claude MD for project-wise standards that always apply constraints like never modify the database schema, framework preferences, and coding style."* La ligne de démarcation est la permanence face à la pertinence. Si l'instruction doit s'appliquer à chaque prompt du projet, elle va dans CLAUDE.md. Si elle n'est utile qu'à certains moments, elle va dans une Skill. ## [01:03] Skills vs sous-agents : contexte partagé vs exécution isolée Les Skills injectent de la connaissance dans la conversation en cours — leurs instructions rejoignent le contexte existant. Les sous-agents fonctionnent différemment : ils reçoivent une tâche, démarrent un contexte d'exécution séparé, travaillent indépendamment et renvoient les résultats sans toucher à la conversation principale. > *"Use sub agents when you want to delegate a task to a separate execution context. You need different tool access that the main conversation does. You want isolation between delegated work and your main context."* Utilisez les Skills quand une expertise doit guider le raisonnement de Claude tout au long d'une conversation. Utilisez les sous-agents quand vous voulez une frontière nette entre la session principale et une unité de travail déléguée — accès différents aux outils, pas de contamination du contexte. ## [01:42] Hooks vs Skills : déclenché par événement vs déclenché par requête Les hooks se déclenchent automatiquement sur des événements — exécuter un linter chaque fois que Claude sauvegarde un fichier, valider une entrée avant un appel d'outil particulier. Ce n'est pas ce que vous demandez qui les déclenche, c'est ce que Claude fait. Les Skills sont à l'opposé : déclenchées par requête, elles s'activent quand une requête leur correspond. > *"A hook might run a llinter every time Claude saves a file or validate input before certain tool calls. They're all event driven, while skills, they're request driven. They activate based on what you're asking."* Si le comportement doit se produire sans condition sur un événement système, c'est un hook. S'il doit orienter la réflexion de Claude quand on lui pose une question, c'est une Skill. ## [02:15] Combiner les cinq pour une personnalisation complète Un setup Claude Code bien configuré attribue à chaque outil son rôle naturel : CLAUDE.md pour les standards de projet toujours actifs, Skills pour l'expertise spécifique à une tâche qui ne doit pas encombrer chaque prompt, hooks pour les effets de bord automatisés, sous-agents pour le travail délégué en isolation, serveurs MCP pour l'accès aux outils externes. Ce ne sont pas des alternatives — ils se composent. > *"Don't force everything into skills when another option fits best. You can use multiple at a time."* Les Skills s'activent automatiquement quand un sujet est pertinent ; CLAUDE.md est toujours présent ; les sous-agents tournent en isolation ; les hooks se déclenchent sur événements ; MCP fournit les outils externes. Choisissez le bon niveau pour chaque préoccupation et combinez-les librement. ## Entités - **Narrateur du tutoriel Anthropic** (Personne) : Animateur de cette série de tutoriels Claude Code skills, s'exprimant au nom d'Anthropic. - **Claude Code** (Logiciel) : Assistant de codage IA d'Anthropic ; sujet de la série de tutoriels. - **Skills** (Concept) : Paquets de connaissances à la demande qui s'activent quand Claude fait correspondre une requête utilisateur ; injectent des instructions dans le contexte de la conversation en cours. - **CLAUDE.md** (Concept) : Fichier de configuration chargé automatiquement dans chaque conversation Claude Code ; utilisé pour les standards et contraintes permanents à l'échelle du projet. - **Sous-agents** (Concept) : Contextes d'exécution séparés instanciés pour traiter des tâches déléguées en isolation de la conversation principale. - **Hooks** (Concept) : Automatisations déclenchées par événements qui se déclenchent sur des actions spécifiques de Claude telles que la sauvegarde de fichier ou les appels d'outils, indépendamment des requêtes utilisateur. - **Serveurs MCP** (Logiciel) : Serveurs Model Context Protocol qui fournissent des outils externes aux sessions Claude Code. - **Anthropic** (Organisation) : Créateur de Claude Code et éditeur de la série de tutoriels Claude Code skills.