Référence des composants de plugin
Skills
Les plugins ajoutent des skills à Claude Code, créant des raccourcis/name que vous ou Claude pouvez invoquer.
Emplacement : répertoire skills/ ou commands/ à la racine du plugin, ou un seul fichier SKILL.md à la racine du plugin
Format de fichier : Les skills sont des répertoires avec SKILL.md ; les commandes sont des fichiers markdown simples
Structure des skills :
- Les skills et les commandes sont découverts automatiquement lors de l’installation du plugin
- Claude peut les invoquer automatiquement en fonction du contexte de la tâche
- Les skills peuvent inclure des fichiers de support à côté de SKILL.md
skills/ et pas de champ manifest skills, un SKILL.md à la racine du plugin est chargé comme une seule skill. Définissez le champ frontmatter name pour contrôler le nom d’invocation de la skill. Sans cela, Claude Code revient au nom du répertoire d’installation, qui pour les plugins installés depuis la marketplace est une chaîne de version qui change à chaque mise à jour. Pour les plugins qui livrent plus d’une skill, utilisez la disposition du répertoire skills/ montrée ci-dessus.
Pour plus de détails, consultez Skills.
Agents
Les plugins peuvent fournir des subagents spécialisés pour des tâches spécifiques que Claude peut invoquer automatiquement si approprié. Emplacement : répertoireagents/ à la racine du plugin
Format de fichier : Fichiers markdown décrivant les capacités de l’agent
Structure de l’agent :
name, description, model, effort, maxTurns, tools, disallowedTools, skills, memory, background et isolation. La seule valeur isolation valide est "worktree". Pour des raisons de sécurité, hooks, mcpServers et permissionMode ne sont pas pris en charge pour les agents fournis par les plugins.
Points d’intégration :
- Les agents apparaissent dans la saisie semi-automatique @-mention sous leur nom délimité, tel que
my-plugin:code-reviewer, une fois que le plugin est activé - Claude peut invoquer les agents automatiquement en fonction du contexte de la tâche
- Les agents peuvent être invoqués manuellement par les utilisateurs
- Les agents de plugin fonctionnent aux côtés des agents Claude intégrés
Hooks
Les plugins peuvent fournir des gestionnaires d’événements qui répondent automatiquement aux événements de Claude Code. Emplacement :hooks/hooks.json à la racine du plugin, ou en ligne dans plugin.json
Format : Configuration JSON avec des correspondances d’événements et des actions
Configuration des hooks :
Types de hooks :
command: exécuter des commandes shell ou des scriptshttp: envoyer l’événement JSON en tant que requête POST à une URLmcp_tool: appeler un outil sur un serveur MCP configuréprompt: évaluer une invite avec un LLM (utilise l’espace réservé$ARGUMENTSpour le contexte)agent: exécuter un vérificateur agentic avec des outils pour les tâches de vérification complexes
if prennent le nom d’outil délimité mcp__plugin_<plugin-name>_<server-name>__<tool>, et le champ server d’un hook mcp_tool prend plugin:<plugin-name>:<server-name>. Une correspondance écrite contre la clé du serveur nu ne se déclenche jamais. Consultez Correspondre les outils MCP et Serveurs MCP fournis par les plugins.
Serveurs MCP
Les plugins peuvent regrouper des serveurs Model Context Protocol (MCP) pour connecter Claude Code avec des outils et services externes. Emplacement :.mcp.json à la racine du plugin, ou en ligne dans plugin.json
Format : Configuration standard du serveur MCP
Configuration du serveur MCP :
- Les serveurs MCP de plugin démarrent automatiquement quand le plugin est activé
- Les serveurs apparaissent comme des outils MCP standard dans la boîte à outils de Claude
- Les capacités du serveur s’intègrent de manière transparente avec les outils existants de Claude
- Les serveurs de plugin peuvent être configurés indépendamment des serveurs MCP de l’utilisateur
Serveurs LSP
Les plugins peuvent fournir des serveurs Language Server Protocol (LSP) pour donner à Claude une intelligence de code en temps réel lors du travail sur votre base de code. L’intégration LSP fournit :- Diagnostics instantanés : Claude voit les erreurs et les avertissements immédiatement après chaque modification
- Navigation de code : aller à la définition, trouver les références et les informations au survol
- Sensibilisation au langage : informations de type et documentation pour les symboles de code
.lsp.json à la racine du plugin, ou en ligne dans plugin.json
Format : Configuration JSON mappant les noms des serveurs de langage à leurs configurations
Format du fichier .lsp.json :
plugin.json :
Champs optionnels :
restartOnCrash et shutdownTimeout nécessitent Claude Code v2.1.205 ou ultérieur. Avant v2.1.205, le schéma de configuration acceptait les deux options mais définir l’une ou l’autre causait à Claude Code de sauter ce serveur LSP entièrement au démarrage, avec la raison visible uniquement dans la sortie claude --debug.
Plusieurs serveurs pour la même extension : quand plus d’un serveur LSP activé déclare la même extension de fichier dans extensionToLanguage, que les serveurs proviennent d’un plugin ou de différents plugins, le premier serveur enregistré gère les fichiers avec cette extension et les autres ne démarrent jamais. L’interface /plugin affiche un avertissement nommant le plugin dont le serveur est actif.
Serveurs qui échouent à initialiser : Claude Code saute un serveur dont la configuration est invalide, par exemple un serveur manquant command ou extensionToLanguage, et les autres serveurs configurés démarrent toujours. Exécutez claude --debug pour voir pourquoi un serveur a été sauté.
Un serveur sauté ne réclame pas ses extensions de fichier, donc un autre serveur valide qui déclare la même extension, du même plugin ou d’un plugin différent, gère toujours ces fichiers. Avant v2.1.205, un serveur qui échouait à initialiser réclamait toujours ses extensions et bloquait un autre serveur valide pour la même extension.
Plugins LSP disponibles :
Installez d’abord le serveur de langage, puis installez le plugin depuis la marketplace.
Moniteurs
Les plugins peuvent déclarer des moniteurs en arrière-plan que Claude Code démarre automatiquement quand le plugin est actif. Chaque moniteur exécute une commande shell pour la durée de la session et livre chaque ligne stdout à Claude en tant que notification, afin que Claude puisse réagir aux entrées de journal, aux changements de statut ou aux événements interrogés sans qu’on lui demande de démarrer la surveillance lui-même. Les moniteurs de plugin utilisent le même mécanisme que l’outil Monitor et partagent ses contraintes de disponibilité. Ils s’exécutent uniquement dans les sessions CLI interactives, s’exécutent sans sandbox au même niveau de confiance que les hooks, et sont ignorés sur les hôtes où l’outil Monitor n’est pas disponible. Emplacement :monitors/monitors.json à la racine du plugin, ou en ligne dans plugin.json
Format : Tableau JSON d’entrées de moniteur
Le monitors/monitors.json suivant surveille un point de terminaison de statut de déploiement et un journal d’erreurs local :
experimental.monitors dans plugin.json sur le même tableau. Pour charger à partir d’un chemin non par défaut, définissez experimental.monitors sur une chaîne de chemin relatif telle que "./config/monitors.json". Les moniteurs sont un composant expérimental.
Champs obligatoires :
Champs optionnels :
La valeur
command prend en charge les substitutions de chemin ${CLAUDE_PLUGIN_ROOT}, ${CLAUDE_PLUGIN_DATA} et ${CLAUDE_PROJECT_DIR}, plus tout ${ENV_VAR} de l’environnement. Préfixez la commande avec cd "${CLAUDE_PLUGIN_ROOT}" && si le script doit s’exécuter à partir du répertoire du plugin lui-même.
Une commande command de moniteur ne peut pas référencer les valeurs ${user_config.*}. La commande s’exécute via un shell, donc Claude Code rejette le moniteur avec une erreur au lieu de substituer la valeur. Les processus de moniteur ne reçoivent pas les variables d’environnement CLAUDE_PLUGIN_OPTION_<KEY>, donc faites en sorte que le script de moniteur lise la valeur à partir d’un fichier de configuration qu’il possède. Avant v2.1.207, les commandes de moniteur substituaient les valeurs ${user_config.*}.
La désactivation d’un plugin en cours de session n’arrête pas les moniteurs qui sont déjà en cours d’exécution. Ils s’arrêtent quand la session se termine.
Thèmes
Les plugins peuvent livrer des thèmes de couleur qui apparaissent dans/theme aux côtés des présets intégrés et des thèmes locaux de l’utilisateur. Un thème est un fichier JSON dans themes/ avec un préset base et une carte overrides clairsemée de jetons de couleur. Les thèmes sont un composant expérimental.
custom:<plugin-name>:<slug> dans la configuration de l’utilisateur. Les thèmes de plugin sont en lecture seule ; appuyer sur Ctrl+E sur l’un d’eux dans /theme le copie dans ~/.claude/themes/ afin que l’utilisateur puisse modifier la copie.
Portées d’installation des plugins
Quand vous installez un plugin, vous choisissez une portée qui détermine où le plugin est disponible et qui d’autre peut l’utiliser :
Les plugins utilisent le même système de portée que les autres configurations de Claude Code. Pour les instructions d’installation et les drapeaux de portée, consultez Installer des plugins. Pour une explication complète des portées, consultez Portées de configuration.
Plugins du répertoire des skills
Tout dossier sous un répertoire de skills qui contient un manifeste.claude-plugin/plugin.json est chargé en tant que plugin nommé <name>@skills-dir à la session suivante, sans marketplace et sans étape d’installation. Générez un avec plugin init. Contrairement à une installation marketplace, le plugin est découvert sur place plutôt que copié dans le cache des plugins.
Un arborescence de répertoire de skills prend en charge trois choses distinctes :
Choisir d’où le plugin se charge
Un plugin de portée projet est archivé dans le référentiel et atteint chaque collaborateur qui le clone. Parce que ce contenu provient du référentiel plutôt que de vous, il se charge seulement après la même porte de confiance qui régit
.claude/settings.json, et les composants qui exécutent du code sont davantage restreints :
- Les serveurs MCP qu’il déclare passent par l’approbation par serveur identique qu’un
.mcp.jsonde projet - Les serveurs LSP démarrent seulement après que vous fassiez confiance à l’espace de travail
- Les moniteurs en arrière-plan ne se chargent pas
Modifier, recharger et désactiver un plugin du répertoire des skills
Les modifications que vous apportez auSKILL.md d’une skill prennent effet immédiatement dans la session actuelle. Les modifications aux autres composants du plugin, tels que hooks/, .mcp.json, agents/ et output-styles/, ne le font pas. Exécutez /reload-plugins ou redémarrez Claude Code pour les récupérer. Consultez Détection des changements en direct.
Pour arrêter le chargement d’un plugin du répertoire des skills, supprimez son dossier ou désactivez-le par nom. Il n’y a pas d’étape uninstall car rien n’a été installé à partir d’une marketplace.
Schéma du manifeste du plugin
Le fichier.claude-plugin/plugin.json définit les métadonnées et la configuration de votre plugin. Cette section documente tous les champs et options pris en charge.
Le manifeste est optionnel. S’il est omis, Claude Code découvre automatiquement les composants dans les emplacements par défaut et dérive le nom du plugin du nom du répertoire. Utilisez un manifeste quand vous devez fournir des métadonnées ou des chemins de composants personnalisés.
Schéma complet
Champs obligatoires
Si vous incluez un manifeste,name est le seul champ obligatoire.
Ce nom est utilisé pour l’espace de noms des composants. Par exemple, dans l’interface utilisateur, l’agent
agent-creator pour le plugin avec le nom plugin-dev apparaîtra comme plugin-dev:agent-creator.
Champs non reconnus
Claude Code ignore les champs de niveau supérieur qu’il ne reconnaît pas. Vous pouvez conserver les métadonnées d’un autre écosystème dansplugin.json et le plugin se charge toujours. Cela rend pratique de maintenir un manifeste unique qui sert également de manifeste d’extension VS Code ou Cursor, un package.json npm, ou un manifeste de bundle MCPB/DXT.
claude plugin validate signale les champs non reconnus comme des avertissements, pas des erreurs. Si un champ est décalé d’un ou deux caractères par rapport à un champ reconnu, l’avertissement suggère le nom probablement prévu. Un plugin avec seulement des avertissements de champs non reconnus réussit toujours la validation et se charge à l’exécution.
Les champs avec le mauvais type échouent toujours. Par exemple, une valeur keywords qui est une chaîne au lieu d’un tableau est une erreur de chargement, et claude plugin validate la signale comme telle.
Passez --strict pour traiter les avertissements comme des erreurs. Utilisez-le dans CI pour détecter un nom de champ mal orthographié ou un champ laissé par l’outil d’un autre avant la publication, même si le plugin se chargerait à l’exécution.
Champs de métadonnées
Activation par défaut
DéfinissezdefaultEnabled: false dans plugin.json pour livrer un plugin qui s’installe désactivé. L’utilisateur l’active avec claude plugin enable <plugin> ou l’interface /plugin. Utilisez ceci pour les plugins qui ajoutent un coût ou une portée qu’un utilisateur devrait accepter, comme celui qui se connecte à un service externe. Cela nécessite Claude Code v2.1.154 ou ultérieur. Les versions antérieures ignorent le champ et activent le plugin à l’installation.
defaultEnabled est le secours quand rien d’autre n’a décidé l’état du plugin. Deux choses ont la priorité sur lui :
- Le paramètre de l’utilisateur : une entrée pour le plugin dans
enabledPluginsà n’importe quelle portée de paramètres. Une fois écrite, elle persiste entre les mises à jour et réinstallations du plugin, donc changerdefaultEnableddans une version ultérieure ne bascule pas un utilisateur existant. - Une exigence de dépendance : quand un plugin est requis par un autre qui est actif, Claude Code écrit
truepour lui au moment de l’installation ou de l’activation. Cela lui donne un paramètre explicite, donc sa propre valeur par défaut ne s’applique plus. Consultez Activer ou désactiver un plugin avec des dépendances.
plugin.json. Consultez Champs de plugin optionnels.
Champs de chemin de composant
Composants expérimentaux
Les composants sous la cléexperimental, themes et monitors, ont un schéma de manifeste qui peut changer entre les versions pendant qu’ils se stabilisent. L’endroit où vous les déclarez est une migration distincte : le niveau supérieur fonctionne toujours, claude plugin validate avertit, et une version future exigera experimental.*.
Configuration utilisateur
Le champuserConfig déclare les valeurs que Claude Code demande à l’utilisateur lors de l’activation du plugin. Utilisez ceci au lieu d’exiger que les utilisateurs modifient manuellement settings.json.
Chaque valeur est disponible pour la substitution en tant que
${user_config.KEY} dans les configurations de serveurs MCP et LSP et les commandes de hook. Les valeurs non sensibles peuvent également être substituées dans le contenu des skills et des agents. Toutes les valeurs sont exportées vers les processus de hook en tant que variables d’environnement CLAUDE_PLUGIN_OPTION_<KEY>, où <KEY> est la clé d’option en majuscules.
Les champs qui s’exécutent dans un shell rejettent ${user_config.*} : substituer une valeur configurée dans une commande shell laisserait le shell exécuter tout ce que cette valeur contient, donc le composant échoue avec une erreur à la place. Chaque champ rejeté a une façon alternative de passer la valeur :
Avant v2.1.207, ces champs substituaient les valeurs
${user_config.KEY} ; mettez à jour les plugins qui s’appuyaient sur ceci.
Les valeurs non sensibles sont stockées sous la clé pluginConfigs dans settings.json en tant que pluginConfigs[<plugin-id>].options. Claude Code écrit la clé dans les paramètres utilisateur et la relit depuis les paramètres utilisateur, l’indicateur --settings, et les paramètres gérés uniquement ; les entrées dans le .claude/settings.json ou .claude/settings.local.json d’un projet sont ignorées. Avant v2.1.207, Claude Code lisait également les paramètres du projet et locaux.
Les valeurs sensibles vont au trousseau macOS, ou à ~/.claude/.credentials.json sur les plates-formes où aucun trousseau pris en charge n’est disponible. Le stockage du trousseau est partagé avec les jetons OAuth et a une limite totale d’environ 2 KB, donc gardez les valeurs sensibles petites.
Canaux
Le champchannels permet à un plugin de déclarer un ou plusieurs canaux de messages qui injectent du contenu dans la conversation. Chaque canal se lie à un serveur MCP que le plugin fournit.
server est obligatoire et doit correspondre à une clé dans les mcpServers du plugin. Le userConfig optionnel par canal utilise le même schéma que le champ de niveau supérieur, permettant au plugin de demander des jetons de bot ou des ID de propriétaire lors de l’activation du plugin.
Règles de comportement des chemins
Qu’un chemin personnalisé remplace ou étende le répertoire par défaut du plugin dépend du champ :- Remplace le répertoire par défaut :
commands,agents,outputStyles,experimental.themes,experimental.monitors. Par exemple, quand le manifeste spécifiecommands, le répertoire par défautcommands/n’est pas analysé. Pour conserver le répertoire par défaut et en ajouter d’autres, listez-le explicitement :"commands": ["./commands/", "./extras/"] - S’ajoute au répertoire par défaut :
skills. Le répertoire par défautskills/est toujours analysé, et les répertoires listés dansskillssont chargés à côté de lui. Exception : pour une entrée de marketplace dont lasourcese résout à la racine de la marketplace, déclarer des sous-répertoires spécifiques remplace l’analyse par défautskills/ - Règles de fusion propres : hooks, Serveurs MCP, et Serveurs LSP. Consultez chaque section pour savoir comment plusieurs sources se combinent
claude plugin list et la vue de détail /plugin. Le plugin se charge toujours en utilisant les chemins du manifeste. Aucun avertissement n’est affiché quand la clé de manifeste pointe dans le dossier par défaut, par exemple "commands": ["./commands/deploy.md"], car le dossier est adressé explicitement dans ce cas.
Pour tous les champs de chemin :
- Tous les chemins doivent être relatifs à la racine du plugin et commencer par
./ - Les composants des chemins personnalisés utilisent les mêmes règles de nommage et d’espace de noms
- Plusieurs chemins peuvent être spécifiés sous forme de tableaux
- Quand un chemin de skill pointe vers un répertoire qui contient directement un
SKILL.md, par exemple"skills": ["./"]pointant vers la racine du plugin, le champ frontmatternamedansSKILL.mddétermine le nom d’invocation de la skill. Cela donne un nom stable indépendamment du répertoire d’installation. Sinamen’est pas défini dans le frontmatter, le nom de base du répertoire est utilisé comme secours.
SKILL.md à sa racine, aucun sous-répertoire skills/, et aucun champ de manifeste skills est automatiquement chargé en tant que plugin à une seule skill dans Claude Code v2.1.142 et versions ultérieures. Vous n’avez pas besoin de définir "skills": ["./"] dans plugin.json pour cette disposition. Le nom d’invocation de la skill suit la même règle que ci-dessus : le champ frontmatter name, ou le nom de base du répertoire comme secours.
Exemples de chemins :
Variables d’environnement
Claude Code fournit trois variables pour référencer les chemins :
Les trois sont exportés en tant que variables d’environnement vers les processus de hook et vers les sous-processus des serveurs MCP et LSP. Les champs où les espaces réservés se résolvent en ligne dépendent du composant du plugin :
Dans les commandes de hook, utilisez la forme exec avec
args pour que chaque chemin soit passé comme un seul argument sans guillemets. Dans les hooks de forme shell et les commandes de moniteur, enveloppez les variables entre guillemets doubles, comme dans "${CLAUDE_PROJECT_DIR}/scripts/server.sh". Ce hook de forme shell exécute un script fourni avec un plugin :
${CLAUDE_PLUGIN_ROOT} change quand le plugin se met à jour. Le répertoire de la version précédente reste sur le disque pendant environ sept jours après une mise à jour avant le nettoyage, mais traitez-le comme éphémère et n’écrivez pas d’état ici.
Quand un plugin se met à jour en cours de session, les commandes de hook, les moniteurs, les serveurs MCP et les serveurs LSP continuent d’utiliser le chemin de la version précédente. Exécutez /reload-plugins pour basculer les hooks, les serveurs MCP et les serveurs LSP vers le nouveau chemin ; les moniteurs nécessitent un redémarrage de session.
Les serveurs MCP peuvent également appeler la requête roots/list pour lire les répertoires de travail de la session à l’exécution. Consultez ce que roots/list retourne et quand Claude Code notifie le serveur des modifications.
Répertoire de données persistantes
Le répertoire${CLAUDE_PLUGIN_DATA} se résout en ~/.claude/plugins/data/{id}/, où {id} est l’identifiant du plugin avec les caractères en dehors de a-z, A-Z, 0-9, _ et - remplacés par -. Pour un plugin installé en tant que formatter@my-marketplace, le répertoire est ~/.claude/plugins/data/formatter-my-marketplace/.
Un usage courant est d’installer les dépendances de langage une fois et de les réutiliser entre les sessions et les mises à jour du plugin. Parce que le répertoire de données survit à n’importe quelle version unique du plugin, une vérification de l’existence du répertoire seul ne peut pas détecter quand une mise à jour change le manifeste de dépendance du plugin. Le motif recommandé compare le manifeste fourni par rapport à une copie dans le répertoire de données et réinstalle quand ils diffèrent.
Ce hook SessionStart installe node_modules à la première exécution et à nouveau chaque fois qu’une mise à jour du plugin inclut un package.json modifié :
diff sort avec un code non nul quand la copie stockée est manquante ou diffère de celle fournie, couvrant à la fois la première exécution et les mises à jour changeant les dépendances. Si npm install échoue, le rm final supprime le manifeste copié pour que la session suivante réessaie.
Les scripts fournis dans ${CLAUDE_PLUGIN_ROOT} peuvent ensuite s’exécuter contre les node_modules persistants :
/plugin affiche la taille du répertoire et demande une confirmation avant la suppression. La CLI supprime par défaut ; passez --keep-data pour le conserver.
Mise en cache des plugins et résolution des fichiers
Les plugins sont spécifiés de deux façons :- Via
claude --plugin-dirouclaude --plugin-url, pour la durée d’une session. - Via une marketplace, installés pour les sessions futures.
~/.claude/plugins/cache) plutôt que de les utiliser sur place. Comprendre ce comportement est important lors du développement de plugins qui référencent des fichiers externes.
Chaque version installée est un répertoire séparé dans le cache. Quand vous mettez à jour ou désinstallez un plugin, le répertoire de version précédente est marqué comme orphelin et supprimé automatiquement 7 jours plus tard. La période de grâce permet aux sessions Claude Code concurrentes qui ont déjà chargé l’ancienne version de continuer à fonctionner sans erreurs.
Les outils Glob et Grep de Claude ignorent les répertoires de version orphelins lors des recherches, donc les résultats de fichiers n’incluent pas le code de plugin obsolète.
Limitations de traversée de répertoires
Les plugins installés ne peuvent pas référencer des fichiers en dehors de leur répertoire. Les chemins qui traversent en dehors de la racine du plugin (comme../shared-utils) ne fonctionneront pas après l’installation car ces fichiers externes ne sont pas copiés dans le cache.
Partager des fichiers au sein d’une marketplace avec des liens symboliques
Si votre plugin doit partager des fichiers avec d’autres parties de la même marketplace, vous pouvez créer des liens symboliques à l’intérieur de votre répertoire de plugin. La façon dont un lien symbolique est traité quand le plugin est copié dans le cache dépend de l’endroit où sa cible se résout :- Au sein du répertoire propre du plugin : le lien symbolique est préservé en tant que lien symbolique relatif dans le cache, donc il continue de se résoudre à la cible copiée au moment de l’exécution.
- Ailleurs au sein de la même marketplace : le lien symbolique est déréférencé. Le contenu de la cible est copié dans le cache à sa place. Cela permet au répertoire
skills/d’un meta-plugin de créer un lien vers les skills définis par d’autres plugins de la marketplace. - En dehors de la marketplace : le lien symbolique est ignoré pour des raisons de sécurité. Cela empêche les plugins de récupérer des fichiers hôtes arbitraires tels que les chemins système dans le cache.
--plugin-dir ou à partir d’un chemin local, seuls les liens symboliques qui se résolvent au sein du répertoire propre du plugin sont préservés. Tous les autres sont ignorés.
La commande suivante crée un lien à partir de l’intérieur d’un plugin de marketplace vers une skill partagée définie par un plugin frère. Sur Windows, utilisez mklink /D à partir d’une invite de commandes élevée ou activez le Mode développeur :
Structure du répertoire des plugins
Disposition standard des plugins
Un plugin complet suit cette structure :CLAUDE.md à la racine du plugin n’est pas chargé comme contexte de projet. Les plugins contribuent au contexte par le biais de skills, d’agents et de hooks plutôt que par CLAUDE.md. Pour livrer des instructions qui se chargent dans le contexte de Claude, mettez-les dans un skill.
Référence des emplacements de fichiers
Référence des commandes CLI
Claude Code fournit des commandes CLI pour la gestion des plugins non interactive, utile pour les scripts et l’automatisation.plugin init
Générez un nouveau plugin à~/.claude/skills/<name>/. À la session Claude Code suivante, il se charge automatiquement en tant que <name>@skills-dir et apparaît dans /plugin et claude plugin list sans étape d’installation.
Consultez Plugins du répertoire des skills pour les exigences de portée et de confiance.
<name>: Nom du plugin. Devient l’espace de noms de la skill et le nom du répertoire sous~/.claude/skills/, donc il ne peut pas contenir d’espaces ou de séparateurs de chemin.
Alias :
new
Chaque valeur --with ajoute un fichier de démarrage pour ce composant, prêt à être modifié :
Le plugin généré utilise la source
@skills-dir plutôt qu’une marketplace. Les administrateurs peuvent bloquer cette source avec strictKnownMarketplaces ou en ajoutant {"source": "skills-dir"} à blockedMarketplaces dans les paramètres gérés. Quand bloqué, plugin init échoue avant d’écrire.
Exemples :
plugin install
Installez un plugin à partir des marketplaces disponibles.<plugin>: Nom du plugin ouplugin-name@marketplace-namepour une marketplace spécifique
La portée détermine quel fichier de paramètres le plugin installé est ajouté. Par exemple,
--scope project écrit dans enabledPlugins dans .claude/settings.json, rendant le plugin disponible à tous ceux qui clonent le référentiel du projet.
Exemples :
plugin uninstall
Supprimez un plugin installé.<plugin>: Nom du plugin ouplugin-name@marketplace-name
Alias :
remove, rm
Par défaut, la désinstallation de la dernière portée restante supprime également le répertoire ${CLAUDE_PLUGIN_DATA} du plugin. Utilisez --keep-data pour le conserver, par exemple lors de la réinstallation après le test d’une nouvelle version.
plugin prune
Supprimez les dépendances de plugins auto-installées qui ne sont plus requises par aucun plugin installé. Les dépendances que Claude Code a intégrées pour satisfaire le champdependencies d’un autre plugin sont supprimées ; les plugins que vous avez installés directement ne sont jamais touchés.
Alias :
autoremove
La commande liste les dépendances orphelines et demande une confirmation avant de les supprimer. Pour supprimer un plugin et nettoyer ses dépendances en une seule étape, exécutez claude plugin uninstall <plugin> --prune.
claude plugin prune nécessite Claude Code v2.1.121 ou ultérieur.plugin enable
Activez un plugin désactivé. Si le plugin déclare des dépendances, Claude Code les active transitivement à la même portée, et la commande échoue quand une dépendance n’est pas installée.<plugin>: Nom du plugin ouplugin-name@marketplace-name
plugin disable
Désactivez un plugin sans le désinstaller. Échoue quand un autre plugin activé dépend de la cible. Le message d’erreur inclut une commande chaînée qui désactive d’abord chaque dépendant.<plugin>: Nom du plugin ouplugin-name@marketplace-name
plugin update
Mettez à jour un plugin vers la dernière version.<plugin>: Nom du plugin ouplugin-name@marketplace-name
plugin list
Listez les plugins installés avec leur version, la marketplace source et le statut d’activation.
Dans une session interactive,
/plugin list affiche le même listing en ligne. La forme interactive accepte --enabled ou --disabled pour afficher uniquement les plugins dans cet état, et ls comme raccourci pour list.
plugin details
Afficher l’inventaire des composants d’un plugin et le coût en tokens projeté. La sortie liste tous les composants que le plugin contribue, regroupés en tant que Skills, Agents, Hooks, serveurs MCP et serveurs LSP, ainsi qu’une estimation du nombre de tokens qu’il ajoute à chaque session. Le groupe Skills inclut à la fois les entréesskills/ et commands/.
<name>: Nom du plugin ouplugin-name@marketplace-name
La sortie affiche deux chiffres de coût pour chaque composant :
- Always-on : tokens ajoutés à chaque session par le texte de liste du plugin, comme les descriptions de compétences, les descriptions d’agents et les noms de commandes, indépendamment du fait qu’un composant se déclenche ou non.
- On-invoke : tokens qu’un composant coûte quand il se déclenche. Affiché par composant, pas comme un total de plugin, car une session typique n’invoque qu’un sous-ensemble de composants.
count_tokens pour votre modèle actif. Les nombres par composant sont proportionnellement mis à l’échelle à partir de ce total. Si l’API est inaccessible, la commande revient à une estimation basée sur les caractères.
plugin tag
Créez une balise de version git pour le plugin dans le répertoire actuel. Exécutez depuis l’intérieur du dossier du plugin. Voir Baliser les versions des plugins.Outils de débogage et de développement
Commandes de débogage
Utilisezclaude --debug pour voir les détails du chargement des plugins :
Cela affiche :
- Quels plugins sont en cours de chargement
- Toute erreur dans les manifestes de plugins
- Enregistrement des skills, agents et hooks
- Initialisation du serveur MCP
Problèmes courants
Exemples de messages d’erreur
Erreurs de validation du manifeste :Invalid JSON syntax: Unexpected token } in JSON at position 142: vérifiez les virgules manquantes, les virgules supplémentaires ou les chaînes non citéesPlugin has an invalid manifest file at .claude-plugin/plugin.json. Validation errors: name: Required: un champ obligatoire est manquantPlugin has a corrupt manifest file at .claude-plugin/plugin.json. JSON parse error: ...: erreur de syntaxe JSON
Warning: No commands found in plugin my-plugin custom directory: ./cmds. Expected .md files or SKILL.md in subdirectories.: le chemin de commande existe mais ne contient aucun fichier de commande validePlugin directory not found at path: ./plugins/my-plugin. Check that the marketplace entry has the correct path.: le cheminsourcedans marketplace.json pointe vers un répertoire inexistantPlugin my-plugin has conflicting manifests: both plugin.json and marketplace entry specify components.: supprimez les définitions de composants en double ou supprimezstrict: falsedans l’entrée de la marketplace
Dépannage des hooks
Le script du hook ne s’exécute pas :- Vérifiez que le script est exécutable :
chmod +x ./scripts/your-script.sh - Vérifiez la ligne shebang : La première ligne doit être
#!/bin/bashou#!/usr/bin/env bash - Vérifiez que le chemin utilise
${CLAUDE_PLUGIN_ROOT}:"command": "\"${CLAUDE_PLUGIN_ROOT}\"/scripts/your-script.sh" - Testez le script manuellement :
./scripts/your-script.sh
- Vérifiez que le nom de l’événement est correct (sensible à la casse) :
PostToolUse, paspostToolUse - Vérifiez que le motif de correspondance correspond à vos outils :
"matcher": "Write|Edit"pour les opérations de fichier - Confirmez que le type de hook est valide :
command,http,mcp_tool,prompt, ouagent
Dépannage du serveur MCP
Le serveur ne démarre pas :- Vérifiez que la commande existe et est exécutable
- Vérifiez que tous les chemins utilisent la variable
${CLAUDE_PLUGIN_ROOT} - Vérifiez les journaux du serveur MCP :
claude --debugaffiche les erreurs d’initialisation - Testez le serveur manuellement en dehors de Claude Code
- Assurez-vous que le serveur est correctement configuré dans
.mcp.jsonouplugin.json - Vérifiez que le serveur implémente correctement le protocole MCP
- Vérifiez les délais d’expiration de la connexion dans la sortie de débogage
Erreurs de structure de répertoire
Symptômes : Le plugin se charge mais les composants (skills, agents, hooks) sont manquants. Structure correcte : Les composants doivent être à la racine du plugin, pas à l’intérieur de.claude-plugin/. Seul plugin.json appartient à .claude-plugin/.
.claude-plugin/, déplacez-les à la racine du plugin.
Liste de contrôle de débogage :
- Exécutez
claude --debuget recherchez les messages « loading plugin » - Vérifiez que chaque répertoire de composants est listé dans la sortie de débogage
- Vérifiez que les permissions de fichier permettent de lire les fichiers du plugin
Référence de distribution et de versioning
Gestion des versions
Claude Code utilise la version du plugin comme clé de cache qui détermine si une mise à jour est disponible. Lorsque vous exécutez/plugin update ou que la mise à jour automatique se déclenche, Claude Code calcule la version actuelle et ignore la mise à jour si elle correspond à celle déjà installée.
La version est résolue à partir du premier de ces éléments qui est défini :
- Le champ
versiondans leplugin.jsondu plugin - Le champ
versiondans l’entrée marketplace du plugin dansmarketplace.json - Le SHA du commit git du plugin source, pour les sources
github,url,git-subdiret relative-path dans une marketplace hébergée sur git unknown, pour les sourcesnpmou les répertoires locaux ne se trouvant pas dans un référentiel git
Si vous utilisez des versions explicites, suivez le versioning sémantique (
MAJOR.MINOR.PATCH) : augmentez MAJOR pour les changements cassants, MINOR pour les nouvelles fonctionnalités, PATCH pour les corrections de bugs. Documentez les modifications dans un CHANGELOG.md.
Voir aussi
- Plugins - Tutoriels et utilisation pratique
- Marketplaces de plugins - Création et gestion des marketplaces
- Skills - Détails du développement des skills
- Subagents - Configuration et capacités des agents
- Hooks - Gestion des événements et automatisation
- MCP - Intégration des outils externes
- Paramètres - Options de configuration pour les plugins