Skills pour agents IA

Vous demandez régulièrement à un agent de relire une page, préparer un rapport ou vérifier un projet selon les mêmes étapes. Au lieu de répéter les consignes à chaque fois, vous pouvez les rassembler dans un skill. L’agent retrouve alors cette méthode lorsque la demande correspond.

Concrètement, un skill pour agent IA est un dossier qui contient au minimum un fichier SKILL.md. Ce fichier explique ce que fait le skill, quand l’utiliser et quelles étapes suivre. Le dossier peut aussi contenir des documents, des modèles ou des scripts utiles à la tâche. [S1] [S2] [S4] [S6]

L’agent ne charge pas tout le dossier en permanence. Il voit d’abord le nom et la description du skill. Il lit les instructions complètes lorsque le skill est sélectionné, puis ouvre les autres fichiers seulement s’il en a besoin. [S1] [S2] [S4]

Choisir le bon mécanisme

Le bon mécanisme dépend de ce que vous voulez rendre réutilisable ou garantir.

Votre besoin	Choisissez
Donner une consigne pour une seule demande	Un prompt
Appliquer une règle à chaque tâche	Une règle permanente, par exemple dans AGENTS.md
Retrouver une méthode dans certaines situations	Un skill
Lire un service ou y effectuer une action	Un outil ou une connexion MCP
Garantir automatiquement un contrôle	Du code, un test, un hook ou un linter
Permettre à d’autres personnes d’installer la capacité	Le mécanisme de distribution du produit, par exemple un plugin

La différence essentielle tient à la fréquence et au niveau de garantie. Un skill guide l’agent lorsqu’une tâche correspond. Une règle permanente s’applique toujours. Un test ou du code convient mieux lorsqu’un contrôle ne peut pas dépendre de l’interprétation du modèle. [S2] [S3] [S4] [S5]

Les skills n’ajoutent pas, à eux seuls, l’accès à un service externe. Ils peuvent expliquer comment utiliser un outil, mais cet outil doit déjà être connecté et autorisé. Dans Codex, un plugin peut regrouper des skills et des connecteurs pour les distribuer. Cette organisation est propre au produit et ne fait pas partie du standard Agent Skills. [S2] [S3]

Quand créer un skill ?

Créez un skill si

• la même méthode revient dans plusieurs demandes ;
• vous pouvez décrire clairement les demandes qui doivent le déclencher ;
• le résultat attendu et la manière de le vérifier sont connus ;
• la méthode comporte assez d’étapes ou de ressources pour mériter d’être conservée ;
• une personne peut maintenir ses instructions, ses exemples et ses éventuels scripts. [S1] [S2] [S5]

Choisissez autre chose si

• le besoin n’a été rencontré qu’une fois et reste mal défini ;
• la consigne doit s’appliquer à toutes les tâches : utilisez une règle permanente ;
• le besoin consiste seulement à accéder à un service : connectez d’abord un outil ;
• un test, un schéma ou une fonction peut garantir entièrement le résultat ;
• vous ne pouvez pas encore distinguer les demandes concernées des demandes voisines ;
• le contenu répète une documentation générale sans apporter de méthode propre au travail. [S3] [S5]

Que doit contenir un skill ?

Le standard Agent Skills exige un dossier et un fichier SKILL.md. Le début de ce fichier contient des informations structurées au format YAML, appelées frontmatter. Les deux champs obligatoires sont name et description. [S1]

Pour être réellement utile, ce minimum technique doit être complété par des instructions compréhensibles :

1. Un nom stable. Il reste court, spécifique et respecte le format du standard. [S1]
2. Une description claire. Elle dit ce que fait le skill, quand l’utiliser et, si nécessaire, quand ne pas l’utiliser. Codex et Claude s’appuient sur cette description pour sélectionner automatiquement un skill. [S1] [S2] [S4] [S5]
3. Un résultat attendu. Le lecteur sait ce qui doit être produit et quand le travail est terminé.
4. Les informations nécessaires. Fichiers, outils, autorisations et décisions à obtenir avant d’agir.
5. Une méthode. Les étapes sont données dans l’ordre, avec les choix qui changent réellement le résultat.
6. Des limites. Le skill indique les actions interdites et les situations qui demandent une validation humaine.
7. Une vérification. Un test, une inspection ou un critère observable montre si le résultat est correct.

Le standard n’impose pas tous ces éléments. Ils constituent une structure pratique pour éviter qu’un skill techniquement valide reste ambigu pendant son utilisation.

Quels fichiers peut-on ajouter ?

• references/ contient les documents détaillés que l’agent ouvre seulement lorsqu’ils deviennent utiles. [S1] [S4] [S5]
• scripts/ contient du code pour une opération répétitive, fragile ou qui doit produire un résultat prévisible. Le langage pris en charge dépend de l’environnement. [S1] [S2]
• assets/ contient les modèles, schémas, images ou données que le skill doit copier ou transformer. [S1]
• license, compatibility et metadata sont des champs optionnels du standard. compatibility sert uniquement lorsque le skill possède des exigences d’environnement particulières. [S1]
• allowed-tools est expérimental dans le standard et son support peut varier ; il ne doit pas être traité comme une frontière de sécurité portable sans vérification du client ciblé. [S1]
• Métadonnées d’interface, modes de déclenchement ou emplacements d’installation sont propres aux produits. Codex, Claude et Copilot n’utilisent pas exactement les mêmes portées ni les mêmes modes de distribution. [S2] [S4] [S6]

N’ajoutez pas ces dossiers « au cas où ». Commencez avec SKILL.md, puis ajoutez une ressource lorsqu’un cas réel montre qu’elle est nécessaire. [S1] [S4] [S5]

Quel niveau de précision choisir ?

• Plus de liberté : donnez des principes et des critères lorsque plusieurs approches peuvent convenir.
• Une méthode préférée : fournissez un modèle ou une suite d’étapes lorsque certaines variations restent acceptables.
• Très peu de liberté : utilisez une commande ou un script borné lorsque l’ordre, la reproductibilité ou la sécurité laissent peu de place à l’interprétation.

Anthropic recommande des instructions plus strictes pour les opérations fragiles. OpenAI conseille des étapes impératives avec des entrées et des sorties explicites, puis des scripts lorsque le résultat doit être prévisible ou dépend d’un outil externe. [S2] [S5]

Un script ne rend pas automatiquement un skill sûr. Avant de l’utiliser, vérifiez sa source, ses dépendances, ses entrées, les fichiers ou services qu’il modifie, ses permissions et son comportement en cas d’erreur.

Comment créer un skill ?

1. Rassemblez trois demandes réelles. Prenez un cas normal, un cas limite et une demande proche qui ne doit pas déclencher le skill.
2. Vérifiez que le skill est le bon mécanisme. Écartez d’abord le prompt ponctuel, la règle permanente, l’outil et le contrôle par le code.
3. Écrivez la description avant les instructions. Testez les mots que les utilisateurs emploient et les demandes voisines à exclure. [S1] [S2] [S4] [S5]
4. Écrivez le chemin minimal. Donnez le résultat attendu, les informations nécessaires, les étapes et la vérification finale. [S2] [S5]
5. Ajoutez des fichiers seulement si nécessaire. Placez les détails dans references/ et les opérations prévisibles dans scripts/. [S1] [S4] [S5]
6. Choisissez la portée. Un skill de projet suit le dépôt. Un skill personnel suit l’utilisateur entre plusieurs projets. Les emplacements exacts dépendent du produit. [S2] [S6]
7. Testez les demandes réelles. Vérifiez le déclenchement, le résultat, les erreurs et les demandes qui ne doivent pas utiliser le skill. [S5]
8. Prévoyez la maintenance. Identifiez la personne responsable et les changements qui imposent une nouvelle revue.

Vérifier un skill

Un validateur peut vérifier la structure du dossier, mais pas la qualité du résultat. Testez le skill sur les comportements qui comptent réellement. [S1]

À vérifier	Preuve attendue
Sélection	Plusieurs formulations prévues déclenchent le skill. Les demandes voisines ne le déclenchent pas.
Résultat	Le cas normal produit le livrable attendu et exécute les vérifications annoncées.
Erreurs	Une entrée absente, invalide ou limite obtient une explication utile.
Sécurité	Les fichiers, services et permissions hors périmètre restent inchangés.
Compatibilité	Le skill est testé dans chaque produit et modèle pour lesquels il est présenté comme compatible.

Codex accepte une activation explicite ou une sélection automatique à partir de la description. Lorsque le produit propose les deux modes, testez-les séparément. Rejouez également ces contrôles après chaque modification importante des instructions ou des scripts. [S2] [S5]

Échecs fréquents

• Description vague. Le skill se déclenche trop souvent ou jamais. Dites ce qu’il fait, quand l’utiliser et employez les mots des demandes réelles. [S1] [S2] [S4] [S5]
• Skill encyclopédique. L’agent charge des connaissances sans lien direct avec la tâche. Gardez la méthode courte et placez les détails dans des références ciblées. [S1] [S4] [S5]
• Règle déguisée. Une contrainte importante ne s’applique que lorsque le skill est sélectionné. Déplacez cette règle vers les instructions permanentes. [S3]
• Outil absent. Le skill suppose une connexion ou une permission qui n’existe pas. Déclarez la dépendance et vérifiez l’accès avant de commencer. [S3]
• Script opaque. Un programme tiers est lancé sans connaître ses effets. Inspectez ses entrées, ses modifications et ses erreurs avant usage.
• Portabilité supposée. Une fonction propre à un produit est présentée comme universelle. Séparez le standard commun des extensions Codex, Claude ou Copilot. [S1] [S2] [S4] [S6]

Questions à se poser avant de créer

1. Le besoin revient-il régulièrement, mais seulement dans certaines situations ?
2. Pourquoi un prompt, une règle, un outil ou du code ne suffit-il pas ?
3. Quelles demandes doivent déclencher le skill, et lesquelles doivent l’éviter ?
4. Quel résultat observable et quelle preuve définissent la réussite ?
5. Quelles entrées, permissions et dépendances sont nécessaires ?
6. Quelle partie peut rester flexible et quelle partie doit être garantie par un script ou un test ?
7. Le SKILL.md minimal suffit-il avant d’ajouter références, scripts ou assets ?
8. La portée est-elle projet, personnelle ou propre à un client identifié ?
9. Les tests couvrent-ils les bons déclenchements, les mauvais déclenchements, les demandes ambiguës, l’exécution, les erreurs et la sécurité ?
10. Qui possède la maintenance et quels changements imposent une nouvelle revue ?

Créez le skill si la méthode, les demandes concernées, le résultat attendu et la personne responsable sont connus. Choisissez un autre mécanisme si le besoin reste ponctuel, doit toujours s’appliquer, peut être entièrement garanti par du code ou dépend d’un outil encore absent. Commencez avec SKILL.md, puis ajoutez une ressource lorsqu’un test réel en montre la nécessité. [S1] [S2] [S3] [S5]