Vous utilisez probablement mal les Agent Skills

Les agent skills — des paquets structurés de connaissances procédurales conçus pour augmenter les LLM agents au moment de l'inférence — connaissent une adoption rapide dans les workflows agentiques, mais sans véritable standardisation ni compréhension partagée de leur bon usage. Un benchmark récent, SkillsBench, publié sur arXiv et relayé sur Hacker News, tente de mesurer leur efficacité réelle sur 86 tâches dans 11 domaines, en testant sept configurations d'agents sur 7 308 trajectoires. Les résultats sont instructifs : des skills soigneusement rédigés augmentent en moyenne le taux de réussite de 16,2 points de pourcentage, mais avec une dispersion considérable selon les domaines — de +4,5 pp en génie logiciel à +51,9 pp en santé. Plus significatif encore, 16 tâches sur 84 affichent un delta négatif, ce qui signifie que des skills mal conçus peuvent activement dégrader les performances.

Le point le plus cité du benchmark — et le plus débattu — concerne les self-generated skills : lorsque l'agent est simplement invité à produire lui-même sa propre procédure avant de résoudre la tâche, le gain moyen est nul. L'auteur du billet considère cette condition expérimentale comme une réinvention dégradée des thinking blocks : demander à un modèle d'écrire une procédure sur quelque chose qu'il ne maîtrise pas revient à lui demander de verbaliser son ignorance, sans apport de connaissance externe réelle.

C'est là que réside l'anti-pattern central identifié dans les pratiques observées en entreprise : créer une skill à la volée, dans une session fraîche, pour répondre à un problème que le modèle rencontre pour la première fois. Une skill produite de cette manière ne contient aucune connaissance que le modèle ne possède pas déjà — elle est donc redondante. Pour être utile, une skill doit encoder une connaissance que le modèle ne peut pas inférer seul : une configuration locale spécifique, un processus métier non documenté publiquement, ou la synthèse d'une résolution d'erreur obtenue après plusieurs itérations coûteuses.

Concrètement, une skill bien conçue prend la forme d'un dossier autonome — un fichier SKILL.md accompagné de scripts, de références et de documentation d'edge cases — permettant à l'agent de ne pas reconstruire à chaque session un contexte qu'il devrait connaître. Cela répond directement à la nature stateless des agents : chaque nouvelle conversation repart de zéro, et un fichier CLAUDE.md seul ne peut pas contenir l'intégralité du contexte d'un projet de taille significative. Les skills servent ainsi de mémoire procédurale externalisée, activée au bon moment selon la nature de la tâche.

Trois usages légitimes se dégagent. Le premier est la capitalisation de contexte : documenter des patterns récurrents mais non triviaux dans un projet donné — configuration Docker spécifique, contraintes d'architecture, procédures de test inhabituelles — pour éviter que l'agent les redécouvre à chaque session. Le deuxième est l'automatisation de tâches répétitives : toute opération que l'utilisateur décrit régulièrement en langage naturel peut être encapsulée dans une skill, économisant du temps et réduisant la variabilité des instructions. Le troisième, le plus exigeant, concerne les problèmes difficiles : après qu'un agent a été débloqué sur une tâche complexe — parfois après une intervention humaine et plusieurs centaines de tokens — il est pertinent de lui demander d'identifier le gap de connaissance qui l'avait initialement bloqué, puis de l'encoder dans une skill pour les sessions futures.

SkillsBench soulève également une question méthodologique non résolue : les conditions testées ne couvrent pas ce cas hybride, où la skill est produite non pas ex nihilo mais à partir d'une résolution humainement assistée et documentée a posteriori. L'auteur du billet indique avoir modifié le benchmark pour tester cette approche et obtenu des résultats nettement supérieurs, sans toutefois disposer des ressources pour valider statistiquement ces résultats à grande échelle.

Le benchmark confirme par ailleurs que des skills focalisées — deux à trois modules ciblés — surpassent une documentation exhaustive. Un modèle plus petit équipé de skills bien conçues peut égaler un modèle plus grand opérant sans elles, ce qui ouvre des perspectives concrètes d'optimisation des coûts d'inférence dans les pipelines agentiques en production.