Les Agent Skills sont devenus le format commun pour transmettre du savoir-faire à un agent de code : un dossier, un fichier SKILL.md, et parfois quelques scripts ou documents de référence. Claude Code, GitHub Copilot, Codex, Cursor ou Gemini CLI savent les lire. Chez nos clients, nous en écrivons beaucoup, et la même question revient vite : comment les distribuer à toutes les équipes, les mettre à jour et éviter que chacun garde sa propre copie dans un coin ?
Jusqu’ici, deux réponses dominaient : un outil d’installation en ligne de commande, ou une marketplace de plugins. Depuis septembre 2026, le Model Context Protocol (MCP) ouvre une troisième voie avec l’extension Skills (SEP-2640). Une issue VS Code récente montre d’ailleurs que les clients commencent tout juste à la supporter.
Dans cet article, nous allons voir ces trois modes de distribution, avec un « getting started » sur la partie MCP, puis les standards ouverts qui les relient et la pratique que nous recommandons chez nos clients : un portail de Skills interne.
Trois chemins pour amener un même SKILL.md jusqu’à l’agent.
📌 Rappel : qu’est-ce qu’un Skill ?
Un Skill est un dossier dont le point d’entrée est SKILL.md : un frontmatter YAML (au minimum name et description), puis des instructions en Markdown. La spec prévoit trois dossiers optionnels pour le reste : scripts/ pour le code exécutable, references/ pour la documentation et assets/ pour les modèles et autres ressources. Le format est décrit dans la spécification Agent Skills.
skills/
└── release-notes/
├── SKILL.md
├── assets/
│ └── template.md
└── scripts/
└── collect-prs.shLe principe clé s’appelle la progressive disclosure. Au démarrage, l’agent ne charge que le nom et la description de chaque Skill. Il lit le SKILL.md complet quand la tâche le demande, et les fichiers annexes seulement s’il en a besoin. On peut donc installer des dizaines de Skills sans saturer le contexte.
La spec ne fixe pas l’endroit où ranger ces dossiers. Le guide destiné aux éditeurs d’outils recommande .agents/skills/ dans le projet et ~/.agents/skills/ pour l’utilisateur, afin qu’un Skill installé pour un agent soit visible des autres. Gardons ce détail en tête : nous y reviendrons en conclusion.
1️⃣ L’outillage : npx skills, APM et gh skill
npx skills et l’annuaire skills.sh
skills.sh est l’annuaire public de Skills édité par Vercel, et skills la CLI qui l’accompagne (vercel-labs/skills). Elle demande Node.js 22.20 ou plus récent.
L’installation se fait depuis n’importe quel dépôt Git :
npx skills add vercel-labs/agent-skills --skill web-design-guidelines -a claude-codeLa commande récupère le Skill puis l’installe pour l’agent choisi avec -a. Par défaut, elle crée une copie de référence et des liens symboliques vers le dossier de chaque agent ; l’option --copy copie les fichiers à la place, et -g installe pour l’utilisateur plutôt que pour le projet. Les sources acceptées vont de owner/repo à une URL GitLab, Azure Repos ou SSH, en passant par un chemin local. Les dépôts privés utilisent vos identifiants Git.
Le reste du cycle de vie est couvert :
npx skills find react # chercher dans l'annuaire
npx skills list # lister les Skills installés
npx skills check # vérifier les mises à jour
npx skills update # mettre à jour
npx skills remove my-skill # supprimer
npx skills init my-skill # créer un squelette de Skill💪 ProTip : npx skills check liste les Skills qui ont une mise à jour, rappelle la commande à lancer pour les installer et sort alors avec le code 1. Par exemple :
↑ humanizer has an update
↑ landing-page-design has an update
2 skill(s) can be updated; run npx skills update to installUne simple étape de CI suffit donc pour repérer les Skills en retard dans un dépôt, puis npx skills update les met à jour.
Côté annuaire, skills.sh affiche un leaderboard (All Time, Trending, Hot) alimenté par la télémétrie anonyme de la CLI. Un Skill y apparaît dès que des utilisateurs l’installent, sans soumission manuelle. La page Audits regroupe les résultats de scans de sécurité de Gen Agent Trust Hub, Socket et Snyk. La télémétrie se désactive avec DISABLE_TELEMETRY=1 ou DO_NOT_TRACK=1.
APM, l’Agent Package Manager de Microsoft
APM (documentation) reprend le modèle d’un gestionnaire de dépendances classique : un manifeste apm.yml, un lockfile apm.lock.yaml et un dossier apm_modules/. Il gère les Skills, mais aussi les instructions, prompts, agents, hooks, plugins et serveurs MCP.
Voici le manifeste d’exemple du README :
name: your-project
version: 1.0.0
targets:
- copilot # choose the harness(es) this project supports
dependencies:
apm:
# Skills from any repository
- anthropics/skills/skills/frontend-design
# Plugins
- github/awesome-copilot/plugins/context-engineering
# Specific agent primitives from any repository
- github/awesome-copilot/agents/api-architect.agent.md
# A full APM package with instructions, skills, prompts, hooks...
- microsoft/apm-sample-package#v1.0.0
mcp:
- name: io.github.github/github-mcp-server
transport: httpPuis, comme avec npm :
apm installapm install résout les dépendances, lance un scan de sécurité intégré, écrit apm.lock.yaml et déploie chaque élément au format de chaque cible détectée (copilot, claude, cursor, codex, gemini…). Pour les Skills, la plupart des cibles convergent vers .agents/skills/, alors que la cible claude écrit dans .claude/skills/. La commande apm compile ne sert qu’aux fichiers d’instructions (AGENTS.md, CLAUDE.md, GEMINI.md).
Pour une organisation, APM apporte surtout de la gouvernance :
apm install --frozenpour une installation reproductible à partir du lockfile ;apm audit --cipour contrôler les dépendances en intégration continue ;apm-policy.ymlpour fixer des règles au niveau de l’organisation ;apm lock export --format cyclonedxpour produire un SBOM.
gh skill, l’alternative intégrée à la GitHub CLI
Si vos équipes ont déjà la GitHub CLI, gh skill évite d’ajouter un outil de plus. La commande est en preview au 5 novembre 2026 et couvre le même cycle de vie avec ses sous-commandes install, list, preview, publish, search et update :
gh skill install github/awesome-copilot documentation-writerLes options --agent et --scope project|user choisissent l’agent et la portée, et --pin fige une version. À la différence de npx skills, gh skill copie les fichiers au lieu de créer des liens. En portée projet, plusieurs agents (GitHub Copilot, Cursor, Codex, Gemini CLI, Antigravity, Amp, Cline, OpenCode, Warp) partagent le même dossier .agents/skills/. La documentation GitHub sur les Agent Skills cite cette commande pour installer des Skills.
2️⃣ Les marketplaces de plugins
C’est le mode de distribution que nous mettons le plus souvent en place chez nos clients. Un plugin regroupe des Skills avec d’autres éléments (commandes, agents, hooks, serveurs MCP), et une marketplace est un dépôt Git qui référence des plugins.
Un marketplace.json pour Claude Code et GitHub Copilot
Le catalogue est un fichier .claude-plugin/marketplace.json à la racine du dépôt. Voici l’exemple minimal de la documentation de Claude Code :
{
"name": "my-marketplace",
"description": "Plugins for my team",
"owner": {
"name": "Your Name"
},
"plugins": [
{
"name": "my-first-plugin",
"source": "./plugins/my-first-plugin",
"description": "A greeting plugin to learn the basics"
}
]
}Le champ source accepte un chemin relatif, un dépôt GitHub ({ "source": "github", "repo": "your-org/my-first-plugin" }), un sous-dossier de monorepo (git-subdir), une URL, une archive ou un paquet npm. On valide, on ajoute la marketplace, puis on installe :
claude plugin validate ./my-marketplace
claude plugin marketplace add your-org/my-marketplace
claude plugin install my-first-plugin@my-marketplaceLes Skills du plugin s’appellent ensuite avec un préfixe, par exemple /my-first-plugin:hello.
Le même fichier sert côté GitHub Copilot :
- Copilot CLI cherche son catalogue dans
marketplace.json,.plugin/marketplace.json,.github/plugin/marketplace.jsonou.claude-plugin/marketplace.json, avec les mêmes champs requis (name,owner,plugins), et s’ajoute aveccopilot plugin marketplace add OWNER/REPOSITORY(documentation) ; - VS Code active les agent plugins avec
chat.plugins.enabledet ajoute des marketplaces via le réglage expérimentalchat.plugins.marketplaces(documentation).
En entreprise, l’intérêt est de préconfigurer la marketplace pour tout le monde, dans le .claude/settings.json du dépôt ou dans les managed settings de Claude Code :
{
"extraKnownMarketplaces": {
"your-marketplace": {
"source": { "source": "github", "repo": "your-org/your-marketplace" },
"autoUpdate": true
}
},
"enabledPlugins": {
"code-formatter@your-marketplace": true,
"deploy-helper@your-marketplace": true
}
}Dans un dépôt, ces réglages s’appliquent après acceptation de la boîte de dialogue de confiance. VS Code lit aussi extraKnownMarketplaces et enabledPlugins dans .claude/settings.json ou .github/copilot/settings.json. Les managed settings de Claude Code peuvent aller plus loin avec strictKnownMarketplaces, une liste des sources autorisées : [] bloque toutes les sources, marketplace officielle comprise (documentation).
⚡️ ProTip : une seule marketplace peut donc servir Claude Code, Copilot CLI et VS Code. C’est la raison pour laquelle nous la conseillons comme socle de distribution.
Agent Plugins, le standard du plugin
Le catalogue est commun, et le plugin lui-même a désormais son standard ouvert : Agent Plugins, une spec « open, vendor-neutral » dont la version 1.0.0 a été taguée le 28 septembre 2026. Son comité technique initial réunit des Core Maintainers d’Amazon, Cursor, Microsoft, OpenAI et Vercel.
La structure est volontairement simple :
my-plugin/
├── plugin.json
├── skills/
│ └── release-notes/
│ └── SKILL.md
└── mcp.jsonLe manifeste plugin.json, à la racine, est obligatoire. Les Skills vivent dans skills/ et doivent respecter la spécification Agent Skills, les serveurs MCP sont déclarés dans mcp.json. Le manifeste minimal ne contient que deux champs :
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "minimal-plugin"
}Côté GitHub Copilot, le standard est déjà là. Copilot CLI traite un plugin.json racine comme un plugin Agent Plugins quand son $schema pointe vers la spec, et le lit en priorité (référence). VS Code reconnaît aussi ce manifeste (référence). Claude Code, lui, lit son manifeste dans .claude-plugin/plugin.json.
À noter : la version 1.0.0 d’Agent Plugins couvre les Skills et les serveurs MCP, et ne définit pas de format de marketplace. Le catalogue reste donc le marketplace.json décrit plus haut.
Exemple : un dépôt de marketplace pour Claude Code et Copilot
Voici l’architecture que nous mettons en place chez nos clients, ici avec un plugin techtown-brand-guidelines :
.
├── .claude-plugin/
│ └── marketplace.json # catalogue pour Claude Code
├── .github/
│ ├── plugin/
│ │ └── marketplace.json # catalogue à l'emplacement recommandé par Copilot CLI
│ └── workflows/ # validation des Pull Requests
└── plugins/
└── techtown-brand-guidelines/
├── .claude-plugin/
│ └── plugin.json # manifeste Claude Code
├── .github/
│ └── plugin/
│ └── plugin.json # manifeste Copilot au format legacy
├── plugin.json # manifeste Agent Plugins
└── skills/
└── techtown-brand-guidelines/
└── SKILL.mdCopilot CLI sait lire .claude-plugin/marketplace.json, mais sa documentation recommande .github/plugin/marketplace.json : garder les deux catalogues lève toute ambiguïté. Côté plugin, chaque outil trouve son manifeste. Claude Code lit .claude-plugin/plugin.json, Copilot CLI et VS Code lisent en priorité le plugin.json Agent Plugins, et .github/plugin/plugin.json garde la compatibilité avec le format legacy de Copilot. Le dossier skills/ est commun à tous.
💪 ProTip : ces manifestes répètent les mêmes informations (nom, description, version). Générez-les depuis une seule source, ou ajoutez une étape de CI qui vérifie qu’ils restent synchronisés à chaque Pull Request.
3️⃣ Partager des Skills directement depuis un serveur MCP
C’est un sujet tout nouveau : l’extension est finale depuis septembre 2026 et les premiers clients l’implémentent à peine. Prenons-le dans l’ordre : ce qui a changé dans la spec, à quoi ça sert, comment l’implémenter et comment le tester.
L’évolution de la spec MCP
L’histoire se joue en deux temps.
- La SEP-2133, mergée en janvier 2026, ajoute un cadre pour les extensions officielles. Un client et un serveur négocient les extensions qu’ils supportent dans
capabilities.extensions, sans toucher au cœur du protocole. - La SEP-2640 « Skills Extension », portée par le Skills Over MCP Working Group, passe au statut Final avec le merge de sa PR le 13 septembre 2026. La spec vit dans le dépôt ext-skills et une page de présentation est disponible sur modelcontextprotocol.io.
La SEP part de trois constats. Un serveur MCP et le Skill qui explique comment l’utiliser sont versionnés et installés séparément. Le champ instructions d’un serveur a une taille limitée, alors que certains Skills dépassent plusieurs centaines de lignes. Enfin, plusieurs projets avaient déjà inventé leur propre schéma skill://, chacun avec sa sémantique.
La réponse est sobre : aucune nouvelle primitive. L’extension s’appuie sur les Resources MCP. Chaque fichier d’un Skill devient une ressource lisible avec le resources/read standard, à une URI de la forme skill://<skill-path>/<file-path>, par exemple skill://pdf-processing/scripts/extract.py. Le dernier segment du chemin doit correspondre au name du frontmatter. Le format du Skill reste celui de la spécification Agent Skills : la SEP ne définit que la manière de le transporter.
Un serveur déclare l’extension dans ses capabilities, avec l’identifiant io.modelcontextprotocol/skills, et doit aussi déclarer resources :
{
"capabilities": {
"extensions": {
"io.modelcontextprotocol/skills": {
"directoryRead": true
}
}
}
}Trois méthodes JSON-RPC s’ajoutent :
skills/list(obligatoire, paginée) liste les Skills disponibles ;skills/get(obligatoire) renvoie le manifeste d’un Skill ;resources/directory/read(optionnelle) permet de parcourir un dossier.
Voici un échange skills/get tiré de la SEP (empreintes raccourcies) :
{ "jsonrpc": "2.0", "id": 5, "method": "skills/get",
"params": { "uri": "skill://pdf-processing/SKILL.md" } }{ "jsonrpc": "2.0", "id": 5, "result": { "resultType": "complete",
"skill": { "uri": "skill://pdf-processing/SKILL.md",
"frontmatter": { "name": "pdf-processing", "description": "Extract, fill, and assemble PDF documents", "metadata": { "version": "2.1.0" } },
"resources": [
{ "uri": "skill://pdf-processing/SKILL.md", "digest": "sha256:d5e6f7a8...", "size": 5120 },
{ "uri": "skill://pdf-processing/scripts/extract.py", "digest": "sha256:f7a8b9c0...", "size": 4096 } ] } } }Le manifeste liste chaque fichier avec sa taille et son empreinte SHA-256. Le client doit vérifier taille, empreinte et frontmatter avant d’utiliser le Skill. L’approbation de l’utilisateur est liée à ce manifeste : si un fichier change, elle est révoquée et doit être redonnée. Les scripts ne s’exécutent pas sans approbation explicite, et un Skill est limité à 512 fichiers et 16 Mio.
La progressive disclosure est conservée : la SEP interdit aux hôtes de télécharger les fichiers d’un Skill avant d’en avoir besoin. Le SKILL.md est lu à l’activation, chaque fichier annexe au moment où l’agent le consulte.
À noter : la SEP précise que les empreintes ne constituent pas une frontière de sécurité. Elles garantissent que vous utilisez bien ce que vous avez approuvé ; la confiance accordée au serveur reste une décision à part.
Un cas d’usage
Prenons une équipe plateforme qui expose un serveur MCP de déploiement avec des outils deploy, rollback et get_logs. Les outils seuls ne disent pas à l’agent dans quel ordre les appeler, quelles conventions de nommage respecter ni à quel moment demander une validation humaine. Ce savoir-faire tient dans un Skill.
Sans l’extension, il faut publier ce Skill ailleurs (marketplace, dépôt) et espérer que sa version reste alignée avec celle du serveur. Avec SEP-2640, le serveur expose lui-même skill://deploy-checklist/SKILL.md. Se connecter au serveur suffit pour découvrir le mode d’emploi, et une nouvelle version du serveur livre le Skill à jour, avec une nouvelle demande d’approbation puisque le manifeste a changé.
Un second cas se dessine : un serveur MCP dont le seul rôle est de servir le catalogue de Skills d’une équipe, sans installation de fichiers sur chaque poste. Ce serveur reste un serveur MCP comme les autres : les questions abordées dans notre article Gouvernance MCP : qui choisit les tools de vos agents de code ? s’appliquent aussi.
Implémenter un serveur avec le SDK TypeScript
Le support est arrivé dans la v2.4.0 du SDK TypeScript le 23 octobre 2026, dans les paquets v2 @modelcontextprotocol/server et @modelcontextprotocol/client (sous-chemin ext/skills). Il ne concerne pas l’ancien paquet v1 @modelcontextprotocol/sdk.
Partons d’un dossier skills/ qui contient un Skill par sous-dossier. Pour nos tests, il en contient deux :
skills/
├── release-notes/
│ ├── SKILL.md
│ └── assets/
│ └── template.md
└── techtown-brand-guidelines/
├── SKILL.md
├── assets/
│ └── techtown-logo.svg
└── references/
├── colors.md
└── typography.mdDans un projet Node.js en mode ES modules ("type": "module"), on installe le SDK :
npm install @modelcontextprotocol/server@2.4.0Puis on écrit server.js. Deux lignes publient tout le dossier, et la dernière branche le serveur sur le transport stdio :
import { McpServer } from '@modelcontextprotocol/server';
import { StdioServerTransport } from '@modelcontextprotocol/server/stdio';
import { loadSkills } from '@modelcontextprotocol/server/ext/skills/node';
const skills = await loadSkills('./skills');
const server = new McpServer({ name: 'team-skills', version: '1.0.0' });
skills.attach(server);
await server.connect(new StdioServerTransport());loadSkills charge le contenu du dossier ./skills, et skills.attach expose ces Skills sur le serveur MCP. Un Skill non conforme est écarté dès le chargement : lors de nos tests, un dossier bad-folder dont le frontmatter déclarait name: other-name a été ignoré avec un avertissement, car le name doit correspondre au nom du dossier. Côté client, SkillsClient liste, lit et vérifie les Skills.
À noter : au 5 novembre 2026, la release note qualifie attach d’expérimental.
En Python, le SDK officiel mcp a mergé le support en octobre 2026, sans release publiée à cette date. FastMCP le propose dans sa version 4.2.0 (en prerelease au 5 novembre 2026), avec un exemple de la documentation qui déclare un Skill directement en code :
from fastmcp import FastMCP, Skill
from fastmcp.skills.provider import SkillCatalogProvider
release_notes = Skill(name="release-notes", description="Write release notes from merged pull requests.",
instructions="# Release notes\n\nGroup changes by theme. Follow template.md.\n",
files={"template.md": "## Highlights\n\n## Fixes\n"})
mcp = FastMCP("Team Skills")
mcp.add_provider(SkillCatalogProvider([release_notes]))Des implémentations sont aussi en cours ou mergées pour C#, Go, Rust, Java, PHP et Ruby.
MCP Inspector le gère déjà ?
Oui, en partie. MCP Inspector a ajouté un onglet Skills dans sa version 2.6.0 (9 septembre 2026). Il affiche les Skills d’un serveur, leur manifeste et un état de conformité, avec un bouton « Verify all » et une vérification fichier par fichier des empreintes. Depuis la 2.13.0, l’Inspector s’appuie sur les schémas du SDK TypeScript.
Nous avons testé les commandes suivantes le 5 novembre 2026 avec l’Inspector 2.14.0 et le SDK TypeScript 2.4.0. Pour l’interface web, on lance l’Inspector en lui passant la commande du serveur :
npx @modelcontextprotocol/inspector node server.jsL’interface démarre sur http://127.0.0.1:6274, avec un jeton d’accès affiché dans le terminal.
Le mode CLI appelle directement les méthodes de l’extension. skills/get renvoie le manifeste d’un Skill, avec la taille et l’empreinte de chacun de ses fichiers :
npx @modelcontextprotocol/inspector --cli node server.js --method skills/get --uri skill://techtown-brand-guidelines/SKILL.md{
"skill": {
"uri": "skill://techtown-brand-guidelines/SKILL.md",
"frontmatter": {
"name": "techtown-brand-guidelines",
"description": "Apply TechTown brand colors, typography and logo rules when creating UI or marketing content."
},
"resources": [
{
"uri": "skill://techtown-brand-guidelines/SKILL.md",
"digest": "sha256:75251b185690f8309696f726b6514e54f68fe8a2da59e5bcfb59923325c9ccd4",
"size": 247
},
{
"uri": "skill://techtown-brand-guidelines/assets/techtown-logo.svg",
"digest": "sha256:03d44c071506cedbeff1f57a5b12c2fc303be223413d378f67f63a2e5b87f62c",
"size": 1910
},
{
"uri": "skill://techtown-brand-guidelines/references/colors.md",
"digest": "sha256:2c6c9923e81506a9c1bdde40b4a3388663b8630a3426552914063ec9afc764c7",
"size": 107
},
{
"uri": "skill://techtown-brand-guidelines/references/typography.md",
"digest": "sha256:eb0da1776ecfd4bec523d43a9dde0e2da7b6e0734adb904352fae3e396f2cf9b",
"size": 58
}
]
}
}Avec --verify, l’Inspector relit chaque fichier, recalcule son empreinte et contrôle la conformité. Sur skills/list, il vérifie tous les Skills du serveur et affiche un rapport JSON par Skill, puis un résumé :
npx @modelcontextprotocol/inspector --cli node server.js --method skills/list --verify{"uri":"skill://release-notes/SKILL.md","name":"release-notes","conformance":[],"frontmatter":[],"files":[...],"ok":true,"outcome":"verified"}
{"uri":"skill://techtown-brand-guidelines/SKILL.md","name":"techtown-brand-guidelines","conformance":[],"frontmatter":[],"files":[...],"ok":true,"outcome":"verified"}
Verified 2 skills and 6 files: no conformance errors.💪 ProTip : en CI, la commande sort avec le code 7 si une vérification échoue et 8 si un Skill n’a pas pu être entièrement vérifié. Ajoutez --require-digests pour sortir en code 9 quand un Skill ne publie pas d’empreintes. Pour un seul Skill, --method skills/get --uri skill://techtown-brand-guidelines/SKILL.md --verify fait la même vérification.
L’onglet Skills de MCP Inspector après « Verify all » : chaque fichier du Skill est vérifié par son empreinte.
La matrice de support des extensions classe l’Inspector en « Partial ». La PR d’origine l’explique : il affiche et vérifie les Skills, mais ne gère ni leur activation ni le consentement par Skill. Ce rôle revient à l’agent.
Et côté clients ?
Au 5 novembre 2026, la matrice coche la colonne Skills pour MCPJam, mcpc (Apify) et Glean, et indique un support partiel pour ChatGPT, fast-agent et MCP Inspector. Les cases de Claude Code, Claude Desktop, Cursor et VS Code GitHub Copilot sont vides.
C’est précisément le sujet de l’issue VS Code #338300, fermée le 4 novembre 2026 avec la PR #345956 (milestone 1.146.0). Le support arrive derrière un réglage expérimental, chat.agentHost.mcpSkills.enabled, désactivé par défaut, et seulement pour les sessions Copilot agent host. Les Skills d’un serveur y apparaissent sous la forme /<server>:<skill>, après une demande de consentement Allow Skills from <server>?.
La spec est finale, les SDK arrivent et les premiers clients suivent en mode expérimental. C’est le bon moment pour expérimenter sur un serveur interne ; pour la production, la marketplace reste notre canal principal.
⚖️ Comparatif des trois approches
| npx skills / APM / gh skill | Marketplace de plugins | Serveur MCP (SEP-2640) | |
|---|---|---|---|
| Unité distribuée | Skill (APM : toutes les primitives) | Plugin (Skills, commandes, hooks, MCP) | Skills exposés par un serveur |
| Installation | CLI, fichiers dans le projet ou le profil | Depuis l’agent, préconfigurable par settings | Connexion au serveur, lecture à la demande |
| Mises à jour | npx skills update, gh skill update, lockfile APM | autoUpdate sur la marketplace | Nouvelle version du serveur, nouvelle approbation |
| Gouvernance | Lockfile, audit et policy (APM) | strictKnownMarketplaces, managed settings | Approbation liée au manifeste, empreintes |
| Maturité au 5 novembre 2026 | Utilisable (gh skill en preview) | Utilisable | Spec finale, clients expérimentaux |
🎯 Conclusion : des standards ouverts et un portail de Skills
Le format des Skills est commun ; ce qui change d’une approche à l’autre, c’est le transport. Les trois vont cohabiter, et ce qui les relie, ce sont des standards ouverts.
Le premier est la spécification Agent Skills. Le 22 octobre 2026, Anthropic l’a donnée à l’Agentic AI Foundation (AAIF), la fondation de la Linux Foundation qui accueille déjà MCP : le nom, le logo, l’organisation GitHub et le domaine agentskills.io. Le standard est désormais maintenu par des ingénieurs d’Anthropic, de Google, d’OpenAI et d’autres entreprises, et l’annonce revendique plus de 70 plateformes d’agents compatibles.
Supporter la norme .agents, c’est ranger ses Skills dans .agents/skills/, l’emplacement que recommande agentskills.io pour l’interopérabilité. Codex, GitHub Copilot, Cursor et Gemini CLI lisent ce dossier, et npx skills, APM comme gh skill y convergent pour la plupart des agents. Claude Code fait exception au 5 novembre 2026 : sa documentation ne liste que les dossiers .claude/skills/, et l’issue #31005 qui demande le support de .agents/skills/ est toujours ouverte. Les outils d’installation compensent en créant le lien ou la copie vers .claude/skills/, et un lien symbolique suffit aussi, comme nous l’avons montré pour Google Antigravity.
Le second est Agent Plugins pour empaqueter Skills et serveurs MCP dans un plugin portable. Associé à une marketplace au format marketplace.json, il donne une base commune pour distribuer des plugins à plusieurs agents depuis un seul dépôt.
Chez nos clients, la bonne pratique que nous mettons en place va plus loin qu’un dépôt : un portail web de Skills, généré à partir du dépôt de la marketplace. On y retrouve :
- une recherche sur le nom, la description et les tags de chaque Skill ;
- la date de dernière mise à jour et la version ;
- le nombre de tokens consommés, en distinguant les métadonnées chargées en permanence (environ 100 tokens selon la spec) du
SKILL.mdchargé à l’activation (moins de 5 000 tokens recommandés) ; - un bouton pour contribuer via une Pull Request, validée en CI.
Maquette d’un portail de Skills : le catalogue devient visible et donne envie de contribuer.
Pour motiver les contributions, nous partageons aussi un Skill qui sert à créer des Skills, sur le modèle de skill-creator du dépôt anthropics/skills : il génère la structure, aide à écrire une bonne description et prépare la PR.
Pour démarrer, un dépôt Git unique suffit : des Skills compatibles .agents/skills/, des plugins au format Agent Plugins, une marketplace qui les référence, et un portail généré depuis ce dépôt. Ajoutez ensuite un serveur MCP interne avec l’extension Skills pour vous faire la main avec MCP Inspector.
👉 Et vous, comment distribuez-vous vos Skills dans vos équipes ?
🎓 Aller plus loin avec MCP
L’extension Skills repose sur les Resources de MCP. Pour comprendre le protocole de l’intérieur, la formation Model Context Protocol (MCP) de TechTown couvre en une journée :
- l’architecture client-serveur et le cycle de vie d’une requête MCP ;
- les trois composants côté serveur : tools, resources et prompts ;
- les SDK Python et TypeScript ;
- la construction de serveurs MCP et d’un agent déployé sur Cloud Run.