Agent Skills rejoint l'Agentic AI Foundation : ce qui change pour les équipes utilisant des agents de code

Le 22 octobre 2026, lors de l'AGNTCon + MCPCon North America à San José, l'Agentic AI Foundation a annoncé quatre nouveaux projets. Celui qui concerne directement toutes les équipes exploitant des agents de développement est Agent Skills, le format SKILL.md, dont Anthropic est à l'origine. Les trois autres sont Open Responses d'OpenAI, OpenEnv d'Hugging Face et OpenSandbox d'Alibaba. La fondation, placée sous l'égide de la Linux Foundation, héberge désormais 10 projets, dont MCP, A2A, AGENTS.md et goose.

L'article annonçant le don d'Anthropic récapitule les éléments transférés : le nom et le logo d'Agent Skills, l'organisation GitHub, le domaine agentskills.io et le standard en lui-même. Il donne également les chiffres d'adoption issus d'Anthropic : plus de 70 plateformes d'agents ont intégré Agent Skills depuis la publication du standard en décembre 2025, et « 1 million de skills ont été publiés et près de 280 millions installés ».

L'annonce a toutes les allures d'une actualité de gouvernance, et c'est en grande partie le cas. Pourtant, elle résout un problème bien concret pour quiconque utilise Claude Code sur une tâche et Codex sur une autre : un skill est-il une fonctionnalité propriétaire ou un format sur lequel on peut bâtir un standard ? C'est désormais un format soutenu par une entité neutre.

En résumé

Agent Skills est désormais un projet indépendant de tout fournisseur au sein de l'Agentic AI Foundation, maintenu par des ingénieurs d'Anthropic, de Google, d'OpenAI et d'autres entreprises intervenant à titre individuel. Aucun aspect du format de fichier n'a changé le 22 octobre. Vos fichiers SKILL.md existants fonctionnent toujours, et les produits compatibles continuent de les charger aux mêmes emplacements. Ce qui change, c'est l'autorité qui décidera de la prochaine version. Pour une équipe, la démarche recommandée consiste à écrire des skills en exploitant uniquement les six champs de la spécification, à en conserver une copie unique par dépôt et à laisser chaque agent la détecter.

Agent Skills en un clin d'œil

Un skill est un répertoire contenant un fichier SKILL.md : un frontmatter YAML comportant au minimum un name et une description, suivis d'instructions en Markdown. Il peut embarquer à ses côtés des répertoires scripts/, references/ et assets/. La spécification est suffisamment concise pour se lire en dix minutes.

Les skills préservent l'espace de contexte grâce au principe de divulgation progressive (progressive disclosure). Au démarrage, un agent charge uniquement le nom et la description de chaque skill — environ 100 tokens chacun selon la spécification —, ne lit l'intégralité du corps de SKILL.md que lorsqu'une tâche concorde, et n'ouvre les fichiers associés que si les instructions y font référence.

Pour une explication plus détaillée et pour apprendre à auditer des skills issus de sources publiques, consultez notre article sur ce qu'est un Skill pour agent de développement.

Ce que cette transition change (et ce qu'elle ne change pas)

Trois aspects changent. D'abord, la propriété de la marque et de l'infrastructure : le nom, le domaine et l'organisation GitHub n'appartiennent plus à un éditeur dont le produit rivalise avec les autres outils capables d'interpréter le format. Ensuite, la gouvernance : des ingénieurs d'Anthropic, de Google et d'OpenAI maintiennent désormais conjointement un format que leurs outils lisent déjà. Enfin, un processus structuré voit le jour, auquel il est possible de participer sans adhérer à la fondation.

Trois aspects ne changent pas, et ce sont ceux qui touchent directement vos dépôts. Le format de fichier reste identique à ce qu'il était le 21 octobre. La spécification ne définit toujours pas où les skills doivent se trouver ; elle précise la structure interne d'un répertoire de skill, et chaque produit décide des dossiers qu'il analyse. Enfin, les extensions propriétaires restent spécifiques à chaque outil : un champ reconnu par un agent pourra tout à fait être rejeté par un autre.

Un détail montre à quel point cette évolution est récente : le 26 octobre, le guide de contribution du dépôt indiquait encore que les demandes d'utilisation du logo « sont examinées par l'équipe Anthropic », et la page de spécification n'affichait aucun numéro de version. Les versions numérotées font partie de la feuille de route proposée, mais ne sont pas encore effectives. En pratique, considérez la spécification comme stable, mais formellement non versionnée pour le moment.

Écrire un skill une fois, l'exécuter dans plusieurs agents

Voici un skill minimal qui respecte la spécification à la lettre. Le champ name est constitué de minuscules, de chiffres et de traits d'union, compte 64 caractères au maximum et coïncide avec le nom du dossier. La description résume le rôle du skill et ses conditions d'utilisation, dans la limite de 1 024 caractères. Tous les autres champs sont optionnels.

.agents/skills/migration-review/
├── SKILL.md
└── references/
    └── CHECKLIST.md

---
name: migration-review
description: Reviews a database migration before it merges. Checks reversibility, locking on large tables, and data backfills. Use when a diff adds or changes files under migrations/ or the user asks for a migration review.
license: Apache-2.0
metadata:
  owner: platform-team
  version: "1.2"
---

# Migration review

1. List every migration file in the diff.
2. For each one, confirm a down migration exists, or state why it cannot.
3. Flag any ALTER TABLE on a table listed in references/CHECKLIST.md as large.
4. Flag backfills that run inside the migration instead of a separate job.
5. Report one line per file: PASS, or FAIL with the reason.

Do not edit the migration. Report only.

Les valeurs de metadata sont des chaînes entre guillemets, car la spécification définit metadata comme un dictionnaire associant des clés et des valeurs sous forme de chaînes de caractères. Le fichier de référence se situe un niveau sous SKILL.md, conformément aux recommandations de la spécification. Validez-le à l'aide de l'outil de référence avant que d'autres collaborateurs n'en dépendent :

skills-ref validate ./.agents/skills/migration-review

Abordons maintenant le volet que la fondation ne prend pas en charge : les chemins de découverte. La documentation des skills de Codex mentionne .agents/skills au niveau du dépôt et $HOME/.agents/skills pour l'utilisateur. La documentation de Claude Code référence .claude/skills/<skill-name>/SKILL.md pour un projet et ~/.claude/skills/ pour l'utilisateur. Ces deux solutions prennent en charge les liens symboliques vers les dossiers de skills. Conservez donc une copie originale unique sous .agents/skills — la convention multi-clients recommandée par le guide d'implémentation client de la spécification — et liez-la pour Claude Code :

mkdir -p .claude/skills
ln -s ../../.agents/skills/migration-review .claude/skills/migration-review
git add .agents/skills .claude/skills

Un seul répertoire, une seule revue de code, un seul endroit à mettre à jour. Les outils qui analysent directement .agents/skills n'ont besoin d'aucun lien ; reportez-vous à la documentation de chaque produit.

Trois règles garantissent la portabilité d'un skill :

• N'utilisez que les six champs de la spécification (name, description, license, compatibility, metadata, allowed-tools) dans la version partagée. La documentation de Claude Code indique que les imports sur claude.ai et l'API Skills rejettent toute autre clé avec une erreur bloquante, alors que Claude Code lui-même tolère des extensions comme context: fork.
• Considérez allowed-tools comme une simple indication. La spécification classe ce champ comme expérimental, et sa prise en charge varie selon les agents.
• Écartez toute configuration propriétaire du frontmatter partagé. Codex lit ses réglages facultatifs d'interface et d'invocation dans un fichier agents/openai.yaml placé au sein du dossier du skill, fichier que les autres agents ignorent.

Adoptez le format standard dès lors que plusieurs agents, ou plusieurs développeurs, interviennent sur un même dépôt. Inutile d'alourdir vos processus si un seul développeur utilise un seul agent : un skill local dans le répertoire spécifique de cet agent suffit amplement, et la question de la portabilité pourra attendre l'introduction d'un second agent.

La question de la sécurité reste entière

Ce n'est pas parce qu'un format est confié à une gouvernance neutre qu'un skill devient sûr par défaut. Le guide d'implémentation client rappelle que les skills au niveau du projet proviennent du dépôt en cours de traitement — qui peut être un clone tout juste récupéré de code que vous ne maîtrisez pas — et recommande aux agents de conditionner le chargement de ces skills à une validation de confiance. La feuille de route proposée par Anthropic prévoit des recommandations de sécurité pour la création et l'installation de skills, ce qui prouve bien que ces directives n'existent pas encore sous une forme aboutie.

D'ici là, auditez un skill comme n'importe quelle dépendance logicielle : lisez attentivement SKILL.md et l'ensemble des scripts avant qu'un agent ne les exécute, appliquez le principe du moindre privilège aux commandes et bannissez tout secret. Avec 1 million de skills publiés d'après Anthropic, l'offre ne manque pas : c'est l'étape d'audit qui fait la différence.

Comment Sharkly s'intègre dans cette dynamique

Un format commun garantit qu'un fichier sera lisible par votre agent. Il ne résout en revanche pas la répartition des skills entre agents, la gestion des droits de modification ni la centralisation des résultats. Cette complexité opérationnelle croît à chaque agent supplémentaire.

Dans Sharkly, un Skill s'appuie sur SKILL.md comme point d'entrée, avec les champs YAML name et description suivis des instructions, conformément à la documentation des Skills. Vous pouvez importer un fichier SKILL.md, un fichier .skill, une archive zip ou un dossier, effectuer un import depuis une URL publique prise en charge, ou récupérer des Skills déjà identifiés par le Runtime d'un Computer. Les imports devenant des copies administrées, la documentation préconise de les vérifier avant de les associer (binding). Chaque Skill est rattaché à une portée précise (Organization, Space ou Agent), verrouillée à la création, et son édition est réservée à son auteur ainsi qu'aux Organization Owners ou Admins. L'article Sharkly Skills passe en revue chacune de ces options.

L'association se configure sur l'Agent, et c'est au niveau de l'Agent que vous choisissez le Runtime. Un Crew correspond à « un groupe réutilisable d'Humains et d'Agents coordonné par un Agent coordinateur », d'après la documentation des Crews, et chaque Agent membre conserve sa propre configuration. Ainsi, un Crew dont le coordinateur s'exécute sur Claude Code et le relecteur sur Codex peut associer le même Space Skill, tout en restituant les résultats de chaque membre au sein de la même Task. Les Agents recherchent, exécutent, testent et documentent. Les équipes humaines décident quant à elles des Skills validés au niveau de l'équipe et approuvent le résultat final.

Vous pouvez synchroniser manuellement vos skills grâce à un répertoire unique et un lien symbolique par dépôt, ou vous appuyer sur Sharkly pour piloter leur déploiement sur vos Agents au fil de la croissance de votre équipe. Si vous souhaitez faire tourner ces deux agents en parallèle, le guide faire cohabiter Claude Code et Codex sur une même base de code détaille la configuration avec git worktree.

FAQ

Le format Agent Skills a-t-il été modifié lors de son transfert vers l'Agentic AI Foundation ? Non. L'annonce porte sur le transfert de la marque, du logo, de l'organisation GitHub, du nom de domaine et du standard. La spécification accessible sur agentskills.io reste identique, et les skills SKILL.md existants continuent de fonctionner sans modification.

Qui assure désormais la maintenance d'Agent Skills ? Des ingénieurs d'Anthropic, de Google, d'OpenAI et d'autres entreprises, à titre individuel, avec David Soria Parra et Mahesh Murag en qualité de Lead Maintainers, d'après le billet d'Anthropic. Anthropic a suggéré la mise en place de versions numérotées et d'un processus officiel d'évolution, mais aucun des deux n'a encore été mis en œuvre.

Quels agents prennent en charge Agent Skills ? Anthropic recense plus de 70 plateformes, citant expressément ChatGPT, Cursor, GitHub Copilot et VS Code. La vitrine des clients sur agentskills.io liste des outils tels que Claude Code, Codex, Gemini CLI, OpenCode, Goose et OpenHands. Chaque solution définissant ses propres répertoires de recherche, reportez-vous à la documentation correspondante.

Faut-il rejoindre la fondation pour concevoir des skills ou y contribuer ? Non. Le billet d'Anthropic précise que vous pouvez continuer à utiliser le standard ou y apporter vos contributions sans adhérer à la fondation. Les échanges sur la spécification se déroulent sur le serveur Discord du projet.

Un skill écrit pour Claude Code est-il compatible avec Codex ? Si son frontmatter s'en tient strictement aux six champs de la spécification et qu'il est placé là où Codex recherche ses fichiers, oui sur le plan du format. Les extensions propres à Claude Code comme context: fork ne seront pas prises en compte : veillez donc à ne pas les inclure dans la copie partagée. Transférer des skills ne constitue qu'un pan de l'interopérabilité ; notre article sur la préservation du contexte lors de la bascule entre agents de développement traite le reste du sujet.