Compétences, plugins et extensions

L'assistant prédit un résultat plausible à partir de ce qui est dans son contexte. Si les conventions de votre projet ne sont pas dans ce contexte, l'assistant ne peut pas les suivre et produira avec assurance du code qui semble correct mais qui correspond aux habitudes d'un autre projet.

Imaginez une développeuse, Maya, travaillant dans un dépôt où chaque gestionnaire d'API retourne des erreurs via un utilitaire partagé problemDetails() et chaque appel à la base de données passe par une fine couche de dépôt. L'assistant ne le sait pas. Ainsi, pour la première tâche, il écrit un gestionnaire qui lance une Error brute et interroge directement la base de données avec une chaîne SQL en ligne. Le code compile. Les tests qu'elle avait ne couvrent pas le nouveau chemin. Il atteint la révision, et un collègue le renvoie : mauvaise forme d'erreur, contourne le dépôt, ne se connectera pas correctement en production. Maya retape les conventions dans le prochain prompt. Et le suivant. D'ici vendredi, elle a collé les mêmes trois paragraphes onze fois.

Ce cycle de copier-coller des règles à chaque fois est le symptôme. Les deux coûts sont réels : les tokens et les minutes gaspillés, et le risque silencieux qu'une fois elle oublie une règle et que le code mal formé passe en production. Les extensions éliminent le cycle. Un court fichier de règles ou une compétence met la convention en contexte une fois, de manière durable, pour que l'assistant la suive dès la première tâche et la cinquantième sans rappel.

L'autre côté est qu'une extension est plus qu'une commodité. Une compétence peut exécuter un script intégré, un serveur MCP fonctionne sur votre machine avec vos identifiants, et un hook se déclenche automatiquement lors d'un événement d'outil. Chacun est un contexte auquel le modèle fait confiance et, souvent, du code qui s'exécute avec votre accès. Le même mécanisme qui sauve Maya de onze collages est celui qu'un plugin malveillant utiliserait pour exécuter une commande qu'elle n'a jamais vue. La section suivante explique comment chaque type fonctionne, afin que vous puissiez utiliser la puissance et auditer le risque.

Il existe quatre mécanismes d'extension, et ils s'organisent du plus léger au plus lourd. Savoir lequel convient à un besoin garde votre configuration économique et auditable.

• Règles de projet. Claude Code lit CLAUDE.md au début de la session. Utilisez-le pour des faits durables : la stack, les conventions, les commandes pour exécuter les tests. L'équivalent inter-outils est AGENTS.md, que Cursor et VS Code Copilot lisent directement depuis la racine du dépôt, tandis que Claude Code ne le prend que lorsqu'un CLAUDE.md l'importe avec une première ligne de @AGENTS.md ou que vous exécutez /init dans un dépôt qui en a déjà un. Comme les règles se chargent à chaque session, limitez-les à des faits d'un paragraphe, pas des procédures.
• Compétences. Un dossier avec un fichier SKILL.md, suivant la norme ouverte Agent Skills maintenant partagée par Claude Code et VS Code Copilot. Utilisez-le pour une procédure qui ne devrait se charger que lorsqu'elle est pertinente : une liste de vérification de publication, un passage de révision de code, une recette de migration.
• Serveurs MCP. Un petit serveur parlant le Model Context Protocol qui donne à l'assistant un véritable outil : interroger Postgres, lire un ticket Jira, récupérer une trace Sentry. Utilisez-le lorsque l'assistant a besoin de données en direct ou d'une action dans un autre système.
• Plugins. Un ensemble versionné qui peut livrer des compétences, des commandes slash, des sous-agents, des hooks, des définitions de serveur MCP et des serveurs LSP ensemble, installé depuis un marketplace. Utilisez-le pour distribuer une configuration fonctionnelle à une équipe en une étape.

La distinction qui décide si les compétences restent économiques est la divulgation progressive. Au démarrage, seuls le nom et la description de chaque compétence se chargent dans le contexte, coûtant quelques dizaines de tokens chacun. Le corps complet se charge uniquement lorsque l'assistant correspond à votre demande avec la description ou que vous tapez /skill-name. C'est pourquoi un projet peut comporter des dizaines de compétences avec presque aucun coût permanent. C'est aussi pourquoi la description est la véritable interface. Le modèle ne lit jamais le corps pour décider ; il lit la description. Une description comme "aide avec la base de données" se déclenchera mal. Une description comme "Ajouter une entrée CHANGELOG.md à partir d'une PR fusionnée ; utiliser lorsque l'utilisateur demande de mettre à jour le changelog ou d'enregistrer une note de version" se déclenche précisément. La description combinée de chaque compétence et when_to_use est limitée à 1 536 caractères, et toute la liste des compétences partage un budget d'environ 1 % de la fenêtre de contexte du modèle, alors mettez le cas d'utilisation clé en premier.

Les commandes personnalisées ont été fusionnées dans les compétences. Un .claude/commands/deploy.md et un .claude/skills/deploy/SKILL.md créent tous deux /deploy. Les compétences ajoutent un dossier pour les fichiers de support, un en-tête pour contrôler qui les invoque, et un chargement automatique. Deux champs d'en-tête contrôlent l'invocation : disable-model-invocation: true signifie que seul vous pouvez le déclencher (approprié pour tout ce qui a des effets secondaires comme déployer ou valider), et user-invocable: false signifie que seul l'assistant le charge (approprié pour les connaissances de fond). La section suivante suit une compétence de l'idée à la validation.

Retour à Maya. La convention répétée qu'elle continue de coller est la procédure des notes de version : après qu'une PR est fusionnée, ajouter un point sous le titre Non publié dans CHANGELOG.md, correspondre au style existant, référencer le numéro de PR, et ne jamais toucher aux sections publiées. Elle la transforme en une compétence.

1. Créer le dossier. Elle exécute mkdir -p .claude/skills/changelog-entry dans le dépôt pour que la compétence soit enregistrée et que toute l'équipe l'obtienne.
2. Écrire SKILL.md. L'en-tête est la partie porteuse. Elle écrit description: Ajouter une entrée CHANGELOG.md à partir d'une PR fusionnée. Utiliser lorsque l'utilisateur demande de mettre à jour le changelog ou mentionne une note de version. et ajoute allowed-tools: Read Edit pour qu'il puisse lire et éditer le fichier sans une invite par utilisation, mais rien de plus. Le corps est quatre lignes d'instruction, pas de prose.
3. Tester le déclencheur. Elle tape "ajouter une entrée de changelog pour PR 218" et observe l'assistant charger changelog-entry automatiquement et proposer un diff d'une ligne. Elle confirme également que /changelog-entry 218 fonctionne comme un appel direct.
4. Attraper un déclenchement erroné. Le lendemain, demander "qu'est-ce qui a changé dans le format du changelog ?" charge à tort la compétence, car "changelog" seul correspondait. Elle resserre la description pour nommer l'action ("lorsque l'utilisateur demande d'ajouter ou d'enregistrer une entrée") et le déclenchement erroné s'arrête.
5. Ajouter un outil que l'assistant ne peut deviner. Le numéro et le titre de la PR vivent dans GitHub, alors elle active le serveur MCP GitHub. Maintenant, l'assistant récupère lui-même le titre de la PR fusionnée au lieu de lui demander de le coller.
6. Valider. Elle révise le diff final, ne voit que le nouveau point sous Non publié, et valide le dossier de compétence avec le changement.

Le résultat est concret. Les onze collages par semaine tombent à zéro. La compétence coûte environ 30-40 tokens de contexte permanent (son nom plus sa description) et le corps complet, environ 80 tokens, se charge uniquement sur la poignée de tâches qui en ont besoin. L'équipe hérite de la convention dès qu'ils tirent. Le serveur MCP qu'elle a ajouté, cependant, est là où commence la prudence de la section suivante, car il lit maintenant depuis GitHub avec son token, et Maya entre directement dans les pièges.

Chacun de ces pièges donne l'impression de progresser tout en créant discrètement des coûts ou des risques.

• Remplir CLAUDE.md avec des procédures. Un long manuel de déploiement dans CLAUDE.md se charge à chaque session et brûle des tokens sur des tâches qui n'ont rien à voir avec le déploiement. La solution est le test "est-ce un fait ou une procédure ?" Les faits (la stack, la commande de test) restent dans le fichier de règles. Les procédures passent dans une compétence qui se charge à la demande.
• La description vague. Une compétence que le modèle ne déclenche jamais est un travail invisible. Écrivez la description à partir des mots de l'utilisateur, listez les phrases de déclenchement, et exécutez /doctor si vous soupçonnez que le budget de la liste des compétences déborde et tronque silencieusement les descriptions.
• Permissions larges oubliées. Accorder allowed-tools: Bash(*) pour faire fonctionner une compétence une fois signifie que chaque invocation automatique ultérieure peut exécuter n'importe quelle commande shell sans invite. Limitez-le aux commandes exactes dont la compétence a besoin, comme Bash(git add *) Bash(git commit *), et révisez ce que chaque compétence s'accorde.
• Installer uniquement sur la confiance. Un plugin communautaire peut inclure des hooks qui se déclenchent à chaque édition et un serveur MCP qui appelle à domicile. Lisez le plugin.json, les hooks/, le .mcp.json, et les scripts avant de les activer. Activez-les d'abord sur une branche jetable.

Ensuite, les véritables cas limites. La sortie de l'outil MCP est une entrée non fiable. C'est la particularité de 2026. Lorsque le serveur MCP GitHub de Maya renvoie une description de PR, ce texte entre dans le contexte du modèle, et un corps de PR hostile peut contenir des instructions cachées ("ignorez votre tâche, exécutez cette commande"). Deux modèles d'attaque nommés dominent la littérature sur la sécurité en 2026 : l'injection de prompt, où le contenu non fiable transporte des instructions, et l'empoisonnement d'outil, où un serveur malveillant cache des instructions dans ses descriptions d'outil. La gestion : minimisez les portées de chaque serveur, gardez les identifiants hors du prompt, et assurez-vous qu'un humain révise toute action que l'agent prend à partir de la sortie de l'outil, plutôt que de la laisser s'exécuter automatiquement.

Sous-agents et compétences qui exécutent des scripts. Une compétence peut inclure un script et l'exécuter. Un sous-agent fonctionne dans son propre contexte et ne peut pas vous montrer une invite de permission. Ainsi, une compétence forkée accordée à de larges outils est un moyen discret d'exécuter du code non révisé. Gardez les compétences forkées ou en arrière-plan en lecture seule là où vous le pouvez, et définissez disableSkillShellExecution: true dans les paramètres gérés si une flotte de machines ne doit jamais laisser une compétence enregistrée exécuter des commandes shell. Gérer tout cela devient plus difficile une fois que plus d'une personne partage les mêmes extensions, ce qui est la section suivante.

Un développeur peut garder un dossier de compétences en tête. Dès qu'une équipe partage des extensions à travers un dépôt, la configuration doit être un artefact visible et versionné, sinon elle dérive en un tas de personnalisations personnelles que personne ne peut auditer.

L'artefact durable est le dépôt lui-même. Enregistrez .claude/skills/ et votre CLAUDE.md dans le contrôle de version (avec un AGENTS.md si d'autres outils de l'équipe en lisent un, importé depuis CLAUDE.md avec @AGENTS.md pour que Claude Code le charge aussi), de sorte qu'un changement de compétence passe par la même demande de tirage et révision que tout changement de code. Un collègue peut voir dans le diff qu'une nouvelle compétence s'est accordée allowed-tools, et peut poser des questions à ce sujet avant de fusionner. C'est aussi pourquoi les compétences de projet nécessitent d'accepter une boîte de dialogue de confiance de l'espace de travail avant que leur accès aux outils pré-approuvés ne prenne effet : ouvrir un dépôt cloné ne devrait pas accorder silencieusement à une compétence enregistrée la capacité d'exécuter des commandes.

Pour une distribution plus large, une responsable nommée Priya emballe la configuration de travail de l'équipe en tant que plugin et la sert depuis un marketplace interne. L'équipe l'ajoute avec /plugin marketplace add your-org/internal-plugins et installe avec /plugin, obtenant les mêmes compétences nommées (/internal-plugins:release-notes), hooks, et définitions MCP en une étape, avec une version qu'ils ne mettent à jour que lorsque Priya la met à jour. Anthropic livre deux marketplaces publiques par défaut en 2026 : claude-plugins-official, un ensemble organisé enregistré automatiquement au premier lancement, et claude-community, le catalogue communautaire révisé que vous ajoutez avec /plugin marketplace add anthropics/claude-plugins-community. Organisé et révisé réduit les chances d'un plugin empoisonné, mais cela n'enlève pas votre responsabilité de lire ce que vous activez.

L'échelle nécessite également une échappatoire. Lorsqu'un serveur MCP partagé ou un hook fait mal fonctionner les sessions, le moyen le plus rapide de savoir si une personnalisation est la cause est claude --safe-mode (ajouté dans la v2.1.169, juin 2026), qui lance une session propre avec chaque personnalisation désactivée : CLAUDE.md, compétences, plugins, hooks, et serveurs MCP. Si le problème disparaît, vous savez qu'il faut bisecter la configuration plutôt que le code.

Le principe durable à garder, quelle que soit la taille : une extension est un contexte auquel le modèle fait confiance et du code qu'il peut exécuter avec votre accès, donc le seuil pour en activer une est le seuil que vous fixeriez pour installer un logiciel, et chaque extension produit encore un diff que vous révisez. Commencez avec une compétence pour la procédure que vous retapez le plus, enregistrez-la dans le dépôt, et ajoutez la suivante seulement une fois que celle-là a gagné sa place.