GitHub standardise les « agent skills » pour apporter des instructions réutilisables à tout agent d'IA
Le nouveau format basé sur des fichiers SKILL.md versionnés permet de capturer des tâches répétables et de les partager entre agents, tout en gardant outils et permissions sous le contrôle de chaque environnement
GitHub a présenté un format standardisé pour capturer le travail d'ingénierie répétable dans des fichiers que les équipes peuvent examiner et réutiliser entre différents agents d'IA. La proposition, détaillée sur le blog de l'entreprise, s'articule autour d'un répertoire versionné dont le cœur est le fichier SKILL.md, qui décrit quand et comment exécuter une tâche.
La discussion s'est tenue en direct pendant GitHub Universe 2026, dans une session avec Shishir Tewari, Senior Data Engineering Manager chez Procore, intitulée « Build once, run on any agent: a practical guide to agent skills ».
Ce qui sépare l'instruction de l'exécution
La prémisse centrale est que la skill porte la connaissance de la procédure mais pas les moyens de l'exécuter. Une skill peut décrire comment interroger une base de données, par exemple, mais elle ne donne pas accès à cette base de données — outils, identifiants et permissions restent spécifiques à l'environnement qui héberge l'agent.
Cette conception résout un problème récurrent : le contexte qui se perd aujourd'hui dans les chats ou reste enfermé dans la tête d'un seul spécialiste. En transformant cette connaissance en fichier versionné, l'instruction devient révisable comme n'importe quel autre artefact de code.
La vérification adversariale comme principe
Le texte utilise l'exemple du Proof Agent, destiné à vérifier les modifications générées par l'IA par rapport à la demande initiale. La règle qui guide la skill est directe : l'auto-vérification n'est pas une vérification. C'est pourquoi un vérificateur indépendant examine les modifications et présente des preuves pour ses conclusions.
Le frontmatter de la skill nomme la tâche et décrit son objectif, tandis que la section « When to Verify » définit quand déclencher la procédure et le reste des instructions détaille ce que le vérificateur examine et quelles preuves inclure.
Le pipeline de données comme cas d'usage
L'exemple Data Forge montre comment plusieurs skills peuvent travailler ensemble. Dans un pipeline de support, la skill forge-init découvre des détails tels que les tables sources et les conventions de nommage, en les consignant dans un manifeste résolu que les autres skills lisent pour obtenir le contexte du projet.
Ensuite, forge-builder coordonne le travail de l'issue jusqu'à la pull request, en utilisant forge-dbx pour interroger la plateforme de données et forge-lint pour appliquer les standards de l'équipe. Une personne examine les décisions proposées au fil du parcours, et la pull request résultante regroupe le code du pipeline, les changements de schéma et les tests.
Chaque skill a une responsabilité définie et partage le contexte du projet au lieu de le redessiner de manière indépendante. Lorsqu'une étape change, une seule skill est modifiée — et la connaissance ne dépend plus de la disponibilité de celui qui la détenait.