Les quatre mécanismes qui étendent Claude Code résolvent des problèmes véritablement distincts. Une compétence enseigne à Claude comment vous voulez que quelque chose soit fait. Un hook garantit que quelque chose se produit, peu importe ce que Claude décide. Un sous-agent protège le contexte de la conversation principale en déléguant un travail ciblé à un processus secondaire isolé. Un serveur MCP donne à Claude accès à un système qu'il ne peut littéralement pas atteindre sans cela. Choisir le mauvais et vous vous retrouvez soit avec une « règle » que le modèle peut silencieusement ignorer, soit avec une dépendance MCP ajoutée là où des instructions simples auraient suffi.
Choisir un mécanisme selon la tâche
Commencez par une seule question de diagnostic : qu'est-ce qui manque réellement ?
Si la réponse est « Claude ne sait pas comment je veux que cela soit fait », c'est une compétence. Format de message de commit, modèles de description de PR, politique de lint, listes de vérification de révision. Tout est du savoir-faire emballé, chargé à la demande quand c'est pertinent, et cela s'exécute dans votre session existante sans dépendance externe.
Si la réponse est « quelque chose doit se produire à un moment fixe et je ne peux pas faire confiance au modèle pour s'en souvenir », c'est un hook. Les hooks se déclenchent sur des événements de cycle de vie comme PreToolUse ou PostToolUse et s'exécutent en dehors du contexte de Claude. Le modèle ne peut pas les contourner. CodingNomads le décrit bien : les hooks s'exécutent de manière déterministe sans implication du LLM et sans coût de contexte.
Si la réponse est « cette sous-tâche entraînerait 40 lectures de fichiers dans mon fil principal », c'est un sous-agent. Fenêtre de contexte séparée, son propre budget de jetons, rend compte d'un résumé. Discret et ciblé.
Si la réponse est « Claude a besoin de toucher réellement à un système qu'il ne peut pas atteindre », c'est un serveur MCP. Lectures de base de données, messages Slack, API internes, pages Notion. Ce ne sont pas des problèmes de connaissance, ce sont des problèmes de connectivité, et seul MCP les résout.
Et CLAUDE.md se situe au-dessus de tous les autres comme la couche toujours active. Chaque session la lit automatiquement. Gardez-la sous 200 lignes, selon les propres recommandations d'Anthropic, sinon les contraintes importantes sont enterrées et ignorées.
Instructions, accès aux outils, événements et contexte isolé
Ce que chaque mécanisme contrôle réellement :
- Compétences : instructions et contexte, chargés à la demande dans la conversation actuelle. Aucun appel externe. Aucun déclencheur d'événement. Le modèle décide quand une compétence est pertinente en fonction de la description dans son en-tête.
- Serveurs MCP : accès aux outils. Claude appelle les outils MCP de la même manière qu'il appelle n'importe quel outil, mais l'exécution se produit dans un processus séparé via JSON-RPC. Un serveur MCP connecte Claude à des systèmes externes ; une compétence lui dit comment les utiliser correctement une fois qu'il est connecté.
- Hooks : événements de cycle de vie. SessionStart, PreToolUse, PostToolUse,
PreCompact. Ils s'exécutent de manière déterministe. Un hook qui bloque une commande destructrice la bloquera à chaque fois, que Claude ait pensé que c'était une bonne idée ou non. - Sous-agents : contexte isolé. Vous confinez une tâche à un sous-agent ; il travaille indépendamment ; il retourne un résultat. Un sous-agent rédacteur de tests n'a pas besoin de connaître votre pipeline de déploiement. Un sous-agent rédacteur de documentation n'a pas besoin de votre schéma de base de données. Cette séparation est tout l'intérêt.
Les compétences et les commandes méritent une brève remarque ici car elles sont faciles à confondre. Selon la documentation officielle des compétences, les commandes personnalisées sont intégrées dans les compétences, pas un sixième système séparé. Elles partagent le même modèle de création SKILL.md. Plus sur cela dans la section suivante.
L'analyse d'Inventive HQ le dit simplement : « Une compétence change le comportement, un sous-agent protège le contexte, un serveur MCP ajoute une capacité, et un hook garantit qu'une action s'exécute de manière déterministe sur un événement, peu importe ce que le modèle décide de faire. »
Où les commandes slash s'inscrivent dans les compétences
Les commandes slash personnalisées ne sont pas un mécanisme distinct qui coexiste avec les compétences. Elles en sont la surface d'invocation. Quand vous tapez /deploy ou /review, vous déclenchez une compétence par son nom. Cette compétence contient les instructions, tous les fichiers de référence associés, et le contexte expliquant comment Claude doit gérer cette tâche.
La tâche de rédaction (écrire un SKILL.md avec de bonnes descriptions en en-tête), la tâche de recherche de commande (décider quel nom de commande exposer), et la tâche de comparaison de mécanisme (choisir entre compétences et hooks) sont trois préoccupations de lecteur distinctes. Elles partagent un format de fichier, ce qui explique en partie pourquoi la confusion persiste.
Si vous décidez d'utiliser une compétence, la question est toujours : s'agit-il d'une connaissance que je devrais sinon retaper, ou d'une chose qui doit s'exécuter en réaction à un événement indépendamment de l'entrée ? La première est une compétence, possiblement exposée comme une commande. La seconde est un hook.
Pour une analyse approfondie de la façon dont CLAUDE.md alimente le contexte du projet dans chaque session, le guide CLAUDE.md pour les agences couvre la portée et la structure des fichiers en détail.
Composer des mécanismes pour une tâche de référentiel
La plupart des configurations réelles ne choisissent pas un seul mécanisme et s'arrêtent là. Elles en composent deux ou trois. Voici un scénario illustratif montrant comment cela se déploie pour un workflow de PR :
| Tâche | Mécanisme | Raison |
|---|---|---|
| Appliquer un format de description de PR | Compétence | Savoir-faire packagé ; se charge quand Claude rédige une PR |
| Récupérer le contexte de ticket depuis Linear | Serveur MCP | Système externe qu'Claude ne peut pas atteindre nativement |
| Analyser >20 fichiers pour une étude d'impact | Sous-agent | Garde le fil principal propre ; retourne un résumé ciblé |
| Bloquer les commits si les tests échouent | Hook | Garantie déterministe ; ne peut pas être contourné par le modèle |
| Règle de nommage de branche toujours active | CLAUDE.md | Jamais conditionnel ; nécessaire à chaque session |
| Exécuter automatiquement le linter avant l'écriture de fichier | Hook sur PreToolUse | Doit s'exécuter sur un événement, pas sur le jugement de Claude |
L'exemple du linter mérite une pause. L'analyse de Moeed le capture précisément : « La partie 'exécuter le linter' est une compétence, Claude peut la faire, vous voulez juste de la cohérence. La partie 'ne commiter que si ça passe' est un hook, c'est une garantie, pas une directive. Ils se composent. »
C'est le modèle mental pratique. Les compétences et les hooks travaillent souvent sur la même tâche sous des angles différents.
Erreurs courantes et comment les corriger
Quelques schémas reviennent régulièrement :
- Serveur MCP pour quelque chose qui n'était que de la connaissance. Si vous vous retrouvez à mettre en place un serveur MCP pour que Claude « accède » à votre guide de style, arrêtez. C'est une compétence. MCP est pour la connectivité aux systèmes actifs, pas pour charger de la documentation markdown.
- Règle CLAUDE.md qui est en réalité un hook. Mettre « ne jamais exécuter
rm -rf» dans CLAUDE.md est une suggestion que le modèle peut techniquement contourner. Un hookPreToolUsequi bloque l'outil Bash sur ce schéma est un arrêt définitif. Si une règle doit être garantie, elle appartient à un hook, pas au contexte. - Compétence pour une tâche qui a besoin de son propre budget de contexte. Si le travail implique de lire des dizaines de fichiers, la fuite de tokens vers votre session principale s'accumule rapidement. Lancez un sous-agent. Il obtient une invite ciblée, fait le travail et retourne un résumé. Votre contexte principal reste cohérent.
- Sous-agent pour quelque chose qui n'avait besoin que d'une instruction. Les sous-agents ont un surcoût. Si Claude a juste besoin de connaître votre convention de migration, écrivez une compétence. Ne lancez pas un travailleur isolé pour un problème de connaissance.
- CLAUDE.md surchargé. Au-delà de 200 lignes, les directives d'Anthropic indiquent que les contraintes critiques se perdent. Déplacez le contenu de référence vers des compétences ou divisez en fichiers
.claude/rules/qui se chargent conditionnellement selon la correspondance de chemin.
Si vous construisez un flux de travail Claude Code à partir de zéro et voulez un point de départ structuré, le guide de flux de travail Claude Code explique comment séquencer ces couches pour une configuration de référentiel réelle.
Suivez le guide d'implémentation approprié
Une fois que vous avez identifié le bon mécanisme, les chemins d'implémentation se divisent clairement. Cet article est une couche de navigation et de comparaison, pas un tutoriel de configuration. Voici où aller ensuite, par mécanisme :
- Configuration des hooks : le guide des hooks Claude Code couvre les événements du cycle de vie, les types de gestionnaires, et comment écrire des gestionnaires shell et HTTP qui s'exécutent de manière déterministe.
- Sous-agents : le guide des sous-agents Claude Code explique comment briefer un sous-agent, limiter ses permissions d'outils et gérer le résultat dans la session parente.
- Serveurs MCP : si vous construisez ou intégrez des serveurs MCP pour une pile de production, le guide de production des serveurs MCP couvre les types de serveurs, le transport et les schémas de fiabilité.
- Compétences : commencez par la documentation officielle des compétences, qui couvre la structure SKILL.md, les descriptions en métadonnées, et comment les commandes personnalisées correspondent aux fichiers de compétences.
N'essayez pas de lire les quatre à la fois avant d'avoir décidé quel mécanisme s'applique. C'est comme ça que vous vous retrouvez trois heures à configurer des hooks alors que vous aviez juste besoin d'une compétence de deux lignes.
FAQ
CLAUDE.md est-il un mécanisme que je dois prendre en compte dans cette décision ?
Oui, mais c'est une décision d'une nature différente. CLAUDE.md n'est pas sélectionné au moment de la tâche. Il se charge automatiquement à chaque session. La question pour CLAUDE.md est : « Claude a-t-il besoin de cette information à chaque fois, sans condition ? » Si oui, mettez-la là. Si l'instruction n'importe que pour certaines tâches, elle appartient à une skill avec une description de frontmatter spécifique.
Une skill peut-elle déclencher un appel à un serveur MCP ?
Oui. Une skill peut instruire Claude d'utiliser les outils MCP disponibles dans le cadre d'un workflow. La skill fournit le comment (quoi demander, dans quel ordre, avec quelles attentes de formatage) et le serveur MCP fournit l'accès. Ils sont complémentaires, pas en concurrence.
Quelle est la différence entre un sous-agent et une équipe d'agents ?
Un sous-agent est un assistant que vous dépêchez depuis la session principale pour gérer une sous-tâche ciblée. Une équipe d'agents est un ensemble de sessions pairs qui peuvent communiquer directement entre elles, adapté à un vrai travail collaboratif en parallèle. Pour la plupart des tâches de dépôt, un sous-agent est le bon choix. Les équipes d'agents ont du sens quand plusieurs workflows indépendants doivent se coordonner plutôt qu'une seule session déléguant vers le bas.
Les hooks ont-ils accès au contexte de Claude ?
Non. C'est le but. Les hooks s'exécutent en dehors du contexte de Claude et le modèle ne peut pas les contourner. Cela en fait l'outil idéal pour les garanties absolues : vérifications de sécurité, passes de linting obligatoires, motifs de fichiers bloqués. Le compromis est qu'un hook ne peut pas prendre de décisions nuancées basées sur ce que Claude comprend de la tâche. Il s'active sur l'événement et exécute son gestionnaire.
Quand a-t-il du sens d'utiliser les quatre mécanismes ensemble ?
Quand vous avez un workflow avec plusieurs modes de défaillance distincts : une lacune de connaissances (skill), une exigence de connectivité (MCP), un risque de fuite de contexte (sous-agent), et au moins une action qui doit être garantie indépendamment du jugement du modèle (hook). La plupart des tâches simples n'en ont besoin que d'un ou deux. Recourir à tous les quatre sur chaque tâche ajoute de la surcharge sans bénéfice.
La distinction la plus nette dans cette comparaison : une skill est une suggestion que Claude lit et suit ; un hook est une règle que le harness applique que Claude soit d'accord ou non. Se tromper sur celui-ci et votre « règle de sécurité » n'est que une demande polie.