Prompts réutilisables

Skill, plugin, marketplace : trois briques de réutilisation, du grain le plus fin au plus large. Le skill code un savoir-faire, le plugin regroupe ce qu’il faut pour l’activer, la marketplace les distribue.

Skills

Un skill code une tâche précise et récurrente, et c’est le LLM qui décide de le charger — pas l’humain (≠ slash command, déclenchée à la main). Seul son front-matter reste en permanence visible ; le corps ne se charge qu’au déclenchement (progressive disclosure). Un savoir-faire répétable, factorisé sans re-prompter et sans saturer le contexte.

• Contenu : front-matter name, description, when_to_use — la partie toujours visible qui décide du déclenchement ; corps avec procédure, exemples, anti-patterns, appels d’outils typiques ; ressources optionnelles (scripts, templates, MCP, commandes embarquées).
• Principe clé : la description et le when_to_use sont les champs les plus critiques — ce sont eux que l’agent lit pour décider. Construire incrémentalement, et benchmarker avec / sans skill pour vérifier le gain réel.
• Granularité : un skill = un savoir-faire. Pas de fourre-tout. Si la procédure devient un enchaînement de phases, c’est un workflow (5.2).
• Quand le mettre à jour : erreur récurrente de l’agent sur cette tâche, évolution de la procédure ou des outils.
• Forme : dossier markdown versionné, front-matter normalisé.

Plugin

Un savoir-faire complet tient rarement dans un seul skill. Le plugin regroupe en bundle installable ce qui va ensemble pour livrer l’ensemble d’un seul bloc (skills, serveurs MCP, slash commands, hooks, sous-agents).

• Contenu : un manifeste qui déclare les composants embarqués (skills, MCP, slash commands, hooks, sous-agents).
• Principe clé : un plugin = une capacité ou un domaine cohérent. Activable et désactivable en bloc, ce qui rend maîtrisable ce qui occupe le contexte du projet.
• Granularité : la couche intermédiaire entre le skill (une tâche) et la marketplace (un catalogue). Un plugin = une capacité ou un workflow complet.
• Quand le mettre à jour : un composant évolue (nouveau skill, montée de version d’un MCP, nouvelle commande) → on reversionne le bundle entier.
• Forme : bundle versionné avec manifeste, installable depuis une marketplace (2.4.3) ou directement depuis un repo.

Marketplace

La marketplace fait passer la capitalisation de l’individuel (un skill dans mon repo) au collectif. Elle mutualise un socle entre projets et entre équipes, sans copier-coller.

À retenir : la marketplace est un index de pointeurs, pas un dépôt du code des plugins.

• Contenu : des entrées qui référencent des plugins avec un nom, description, versions disponibles, source / auteur, statut de revue.
• Principe clé : centraliser pour vérifier la provenance, le versionnement et la revue (qualité, sécurité) avant adoption. La marketplace rend les plugins découvrables.
• Granularité : interne à l’équipe (socle maison) ou publique. Une marketplace = un périmètre de confiance.
• Quand le mettre à jour : nouveau plugin à publier, nouvelle version d’un plugin existant, retrait d’un plugin déprécié.
• Forme : un registre (manifeste / catalogue) qui liste plugins et sources, référencé par une URL ou un repo. On s’y abonne, puis on installe et met à jour à la demande depuis ce point unique.

Skill, plugin, marketplace forment la chaîne qui transforme un savoir-faire ponctuel en patrimoine partagé. Le chapitre suivant change d’échelle : on quitte le contexte qui survit au projet pour entrer dans celui qui ne vit que le temps d’une tâche.