Skills vs. autres fonctionnalités de Claude Code — Introduction aux Agent Skills

Claude Code offre toute une couche d’extensions : CLAUDE.md, règles, styles de sortie, skills, sous-agents, hooks, serveurs MCP, plugins. Elles se ressemblent de loin et répondent de près à des questions différentes. La page officielle Extend Claude Code les distingue par ce qu’elles chargent, quand, et à quel coût. Cette leçon reprend cette grille pour que chaque besoin trouve son mécanisme, et pour éviter l’erreur classique : tout faire entrer de force dans les skills parce que c’est la fonctionnalité que l’on vient d’apprendre.

Toujours chargé, à la demande, ou sur événement

Fonctionnalité	Ce qu’elle fait	Quand l’utiliser	Coût en contexte
CLAUDE.md	Contexte permanent, lu à chaque session	Conventions, « toujours faire X »	À chaque requête
Règles `.claude/rules/`	Instructions scopées par chemin (`paths`)	Règles d’un langage ou d’un dossier	Quand les fichiers correspondent
Style de sortie	Rôle, ton, format des réponses	Réponses plus courtes, un autre rôle	À chaque requête
Skill	Savoir et procédures, appelables	Contenu réutilisable, tâches répétables	Description seulement, corps au déclenchement
Sous-agent	Boucle isolée qui renvoie un résumé	Lire beaucoup de fichiers, travail en parallèle	Isolé de la session
Hook	Script, requête HTTP, prompt ou agent lancé sur un événement	Ce qui doit arriver à chaque fois	Zéro, sauf si le hook renvoie du contexte
MCP	Connexion à des services externes	Données ou actions hors du dépôt	Noms des outils, schémas à la demande
Plugin	Emballage de skills, agents, hooks, serveurs	Même configuration dans plusieurs dépôts, diffusion	Celui de ses composants

CLAUDE.md ou skill ?

CLAUDE.md se charge dans chaque conversation, quoi que vous demandiez. C’est la bonne place pour ce qui ne souffre aucune exception : si votre projet exige TypeScript en mode strict, la règle doit être présente autant lorsque Claude écrit un composant que lorsqu’il corrige un test à trois heures du matin. Un skill se charge à la demande. Le test qui départage les deux est simple : si l’instruction ne sert que dans une fraction de vos échanges, la placer dans CLAUDE.md revient à faire porter son coût à toutes les autres conversations. La règle d’or de la documentation : moins de 200 lignes dans CLAUDE.md ; au-delà, déplacez les références dans des skills et les règles locales dans .claude/rules/.

Un skill peut être référence (une connaissance que Claude applique au travail en cours : conventions d’API, guide de style) ou action (une procédure que vous déclenchez : /deploy, /release). Les deux s’écrivent dans le même fichier ; seule l’intention change, et avec elle le choix de disable-model-invocation.

Skills et sous-agents

Un skill enrichit la conversation en cours : ses instructions rejoignent le contexte existant, avec tout l’historique, et s’appliquent aux échanges suivants. Un sous-agent fait l’inverse : il tourne dans un contexte séparé, reçoit une tâche, travaille de manière indépendante et ne renvoie qu’un résumé. L’isolement est la fonctionnalité, pas un effet de bord. Utilisez un sous-agent quand la tâche lirait des dizaines de fichiers que vous ne relirez pas, ou quand votre fenêtre se remplit.

Les deux se combinent dans les deux sens. Un sous-agent personnalisé peut précharger des skills (champ skills: de son en-tête) : leur contenu complet entre dans son contexte au démarrage. Et un skill peut s’exécuter dans un sous-agent (context: fork), ce qui garde ses lectures hors de votre conversation. Un point souvent mal compris : sans skills:, un sous-agent peut quand même découvrir et invoquer vos skills de projet, personnels et de plugin par son outil Skill ; le préchargement ne fait que lui éviter de les chercher. Pour l’en empêcher, retirez Skill de ses outils.

Skills et hooks

Un hook se déclenche sur un événement, indépendamment de ce que vous demandez : il lance le formateur à chaque fichier modifié, qu’il s’agisse d’une refonte ou d’une faute de frappe. Un skill est piloté par la demande. La différence tient en un mot, déterminisme : Claude Code exécute un hook sans que le modèle ait à décider ; Claude interprète un skill, et le résultat peut varier. La documentation en tire la règle des garde-fous : « ne modifie jamais .env » dans un skill ou dans CLAUDE.md est une demande ; un hook PreToolUse qui bloque la modification est une garantie. Si une règle doit tenir à chaque fois, c’est un hook.

Les deux se combinent aussi : l’en-tête d’un skill peut déclarer des hooks, actifs à partir de son invocation. Un /release peut ainsi garantir que la suite de tests tourne avant chaque commit, quoi que Claude décide. Et la sortie d’un hook atterrit dans le contexte : un hook qui lance le linter renvoie ses erreurs à Claude, un skill /fix-lint lui dit comment les corriger.

Les serveurs MCP, une catégorie à part

Un serveur MCP fournit des outils et des données externes : il étend ce que Claude peut faire, là où un skill change comment il le fait. Brancher le serveur de votre outil de tickets ne dit rien de la façon dont vous voulez qu’un ticket soit rédigé ; c’est le rôle d’un skill. Les deux vont de pair : le serveur apporte la connexion et l’authentification, le skill documente votre schéma, vos conventions de requête, votre format de message.

Quand ajouter quoi

Inutile de tout configurer d’avance. La documentation propose des déclencheurs, dans l’ordre où la plupart des équipes les rencontrent :

Déclencheur	Ajoutez
Claude se trompe deux fois sur une convention ou une commande	Une ligne dans `CLAUDE.md`
Vous demandez sans cesse des réponses plus courtes ou un autre format	Un style de sortie
Vous retapez le même prompt pour démarrer une tâche	Un skill que vous invoquez
Vous collez le même mode opératoire pour la troisième fois	Un skill
Vous copiez des données d’un onglet que Claude ne voit pas	Un serveur MCP
Une tâche annexe inonde la conversation de sorties que vous ne relirez pas	Un sous-agent
Quelque chose doit arriver à chaque fois, sans demander	Un hook
Un second dépôt a besoin de la même configuration	Un plugin

Les mêmes déclencheurs disent quand mettre à jour l’existant : une erreur répétée est une ligne de CLAUDE.md, pas une correction ponctuelle ; un workflow que vous retouchez à la main est un skill qui a besoin d’une révision.

À vous de jouer

Ouvrez votre CLAUDE.md et comptez les lignes qui ne servent que dans un cas sur dix. Déplacez-en une dans un skill de référence (user-invocable: false).
Prenez une règle « ne jamais… » de ce fichier et transformez-la en hook PreToolUse ou en règle de permission deny. Testez que Claude ne peut plus la contourner.
Créez un sous-agent dans .claude/agents/ qui précharge votre skill de revue (skills: [pr-review]), puis comparez une revue faite par le sous-agent et une revue faite dans la conversation.

Sources officielles : Extend Claude Code · Extend Claude with skills · Create custom subagents · Automate actions with hooks

Points clés à retenir

CLAUDE.md pour ce qui vaut toujours (moins de 200 lignes), règles par chemin pour le local, skill pour ce qui sert parfois
Un skill enrichit la conversation ; un sous-agent isole ; ils se combinent (skills: dans l’agent, context: fork dans le skill), et un sous-agent peut invoquer les skills même sans préchargement
Un hook est déterministe, un skill ne l’est pas : les garde-fous vont dans les hooks, y compris dans l’en-tête d’un skill
MCP étend ce que Claude peut faire ; le skill explique comment s’en servir
Ajoutez chaque mécanisme sur son déclencheur, pas d’avance