Un plugin regroupe ce que vous avez déjà écrit — commandes, sous-agents, skills, hooks — dans un dossier que quelqu'un d'autre peut installer. Le manifeste est petit et peu polémique, et c'est bien pourquoi ses erreurs agacent : une version qui n'en est pas une, un nom avec une majuscule, un site sans schéma. Aucune n'empêche le fichier d'être du JSON valide, et toutes causent des ennuis plus tard. Ce créateur remplit les champs, vérifie ceux qui ont des règles et montre l'arborescence attendue autour, car le manifeste seul ne fait rien : ce sont les dossiers voisins qui sont chargés.
Fonctionnalités
Nom vérifié contre les règles de nommage
Version vérifiée comme version sémantique, préversions incluses
Auteur et courriel imbriqués correctement plutôt qu’aplatis
Site vérifié pour son schéma
Les champs vides sont omis plutôt qu’écrits à blanc
L’arborescence affichée à côté du manifeste
Mots-clés saisis un par ligne
Se télécharge en plugin.json
Comment utiliser Manifeste de plugin
Nommez le plugin et donnez-lui une version de départ
Décrivez ce qu’il regroupe
Ajoutez auteur, site et licence si vous le partagez
Téléchargez plugin.json dans le dossier .claude-plugin
Exemple
Entrée
"version": "1.0"
Sortie
Error: not a semantic version — use major.minor.patch
Les versions en deux parties sont le refus le plus fréquent.
Erreurs courantes et dépannage
La version est refusée. — Une version sémantique a trois parties : 1.0.0, pas 1.0. Un suffixe de préversion comme 1.0.0-beta.1 convient.
Le plugin est introuvable après installation. — Le manifeste va dans .claude-plugin/plugin.json à l’intérieur du dossier du plugin, pas à sa racine. L’arborescence sous la sortie montre où va chaque chose.
Le nom est refusé. — Minuscules, chiffres et tirets simples. Il sert d’identifiant : majuscules et espaces sont exclus.
Rien ne se charge malgré un manifeste valide. — Le manifeste ne fait que décrire le plugin. Commandes, agents, skills et hooks sont chargés depuis les dossiers voisins : un plugin vide au manifeste parfait ne fait rien.
Foire aux questions
Que peut contenir un plugin ?
Toute combinaison de commandes slash, définitions de sous-agents, skills et hooks, chacune dans son dossier à côté du manifeste. Tout est facultatif : un plugin qui livre une commande utile est un plugin parfaitement valable.
Quels champs sont vraiment obligatoires ?
Le nom, en pratique. Le reste est de la métadonnée qui rend le plugin utilisable par d’autres : une description pour savoir ce que c’est, une version pour repérer les changements, un site pour trouver la source.
Comment versionner ?
Commencez à 0.1.0 tant que cela bouge, et traitez le premier nombre comme la promesse de compatibilité que vous faites. Renommer une commande ou retirer une skill est une rupture pour ceux qui l’utilisent.
Le champ licence est-il nécessaire ?
Seulement si vous partagez. Et si vous partagez, le dire explicitement épargne une conversation : un dépôt sans licence est juridiquement inconfortable à réutiliser, même quand il est manifestement fait pour cela.
Puis-je bâtir un plugin avec l’existant ?
C’est ainsi que cela commence en général. Les commandes et skills qui fonctionnent déjà migrent sans modification dans les bons dossiers ; le manifeste est le seul fichier nouveau.
Outils associés
Générateur de commandes — Créez une commande personnalisée, avec arguments et liste d'outils.
Générateur de sous-agents — Créez le fichier de définition d'un sous-agent, outils et modèle compris.
Générateur de skills — Écrivez un SKILL.md dont le frontmatter est vérifié à la frappe.
Générateur de hooks — Créez des hooks settings.json et repérez les matchers qui ne se déclenchent jamais.