Quand Hermes Agent s'est ouvert au public le 12 mars, la release embarquait plus de soixante-dix skills intégrés répartis sur une quinzaine de catégories. Quatre semaines plus tard, un marketplace communautaire de skills tournait sur agentskills.io avec des centaines de skills supplémentaires. Ce billet raconte comment c'est arrivé — et pourquoi l'architecture de skills de Hermes vaut le coup d'être comprise, même si tu ne comptes jamais en écrire un.
Ce qu'est vraiment un skill
Dans la plupart des frameworks d'agents IA, un « outil » est une fonction Python que le développeur enregistre au moment de l'import. Tu décores une fonction, tu écris un docstring, tu la ranges dans un tableau de tools quelque part. Quand l'agent en a besoin, le framework injecte sa description dans le prompt et parse la sortie d'appel d'outil du modèle.
Un skill Hermes, ce n'est pas ça. C'est un bundle déclaratif avec un manifeste (skill.yaml), des scripts exécutables ou des entrypoints Python, une description de ses prérequis, et une politique d'activation. Au démarrage, Hermes parcourt le répertoire de skills, lit chaque manifeste, et décide lesquels sont disponibles pour cette session en vérifiant si leurs prérequis sont réellement présents sur la machine — variables d'environnement, binaires dans le PATH, entrées de config, capacités de la plateforme.
Un skill qui a besoin de ffmpeg n'est même pas présenté à l'agent sur une machine où ffmpeg n'est pas installé. Un skill qui nécessite un token de bot Telegram ne s'active que dans une session connectée à Telegram. Le prompt de l'agent ne contient jamais que les skills que tu peux réellement utiliser à cet instant.
Ça a l'air d'un détail. C'est la raison pour laquelle un agent peut embarquer soixante-dix skills dès le premier jour sans faire exploser le prompt.
Le Skills Hub et ce qu'il fait
Depuis la v0.2.0, Hermes est livré avec le Skills Hub — un index local de chaque skill disponible dans ton installation, avec des métadonnées, l'attribution de la source et une couche d'activation conditionnelle. Tu peux lancer hermes skills list pour voir ce qui est installé, hermes skills enable <nom> ou hermes skills disable <nom> pour activer ou désactiver, et hermes skills info <nom> pour consulter le manifeste, la source et les prérequis exacts.
Le Hub est aussi l'abstraction dans laquelle les skills communautaires viennent se brancher. Un auteur de skill publie un manifeste plus un paquet source ; les utilisateurs l'installent en une seule commande ; le Hub valide les prérequis et les règles d'activation exactement comme pour les skills intégrés. Il n'y a pas de voie spéciale pour les skills « officiels » par rapport aux « communautaires » — ce sont tous juste des skills.
Quatre semaines après le lancement, ce Hub a pris un visage public : agentskills.io. C'est un annuaire web de skills créés par la communauté, avec recherche, catégories, métriques de popularité et une commande d'installation standardisée. Imagine le npm ou le pip des capacités d'agents, en plus ciblé : chaque skill est censé faire une seule chose, et il est livré avec un manifeste qui dit à Hermes comment l'utiliser en toute sécurité.
Pourquoi l'écosystème a grandi si vite
Quatre semaines pour passer de zéro à des centaines de skills communautaires, c'est court. Plusieurs choix d'architecture l'ont rendu possible.
Le manifeste est l'interface. Un auteur de skill n'a qu'à bien écrire son manifeste. Prérequis, description, schéma d'entrée, conditions d'activation — tout va dans skill.yaml. L'implémentation peut être en Python, en shell, un binaire exécutable, tout ce vers quoi le manifeste pointe. Les contributeurs n'ont pas besoin d'apprendre un SDK propre à Hermes pour écrire quelque chose d'utile. Ils décrivent ce que fait leur outil dans un fichier YAML dont le format existait déjà pour les skills intégrés.
Les prérequis sont structurels, pas documentés. Si un skill a besoin de ffmpeg, le manifeste le déclare, et Hermes vérifie. Tu n'installes pas un skill cassé qui échoue silencieusement au runtime parce qu'il manque une dépendance — le Hub te dit ce qui manque et refuse d'activer. Les auteurs peuvent poser des hypothèses, et les utilisateurs peuvent leur faire confiance.
L'activation est conditionnelle. Un skill peut déclarer qu'il ne s'active que sur Telegram, que quand telle variable d'environnement est définie, que quand tel fichier existe, que dans certains répertoires de travail. Le prompt que voit l'agent est taillé sur mesure pour le moment. Tu peux installer cent skills et l'agent n'en verra jamais quatre-vingt-dix dans une session donnée — le prompt ne gonfle pas.
Sandbox-friendly par défaut. Les skills qui exécutent du code le font à l'intérieur des couches de sandbox existantes de Hermes — l'isolation par git worktree et le système de checkpoints du système de fichiers livrés avec la v0.2.0. Un skill communautaire qui déraille ne peut pas détruire ton code ni tes fichiers, parce que le sandbox est intégré à l'agent, pas au skill. Ça fait chuter drastiquement le coût de confiance quand tu installes quelque chose de nouveau.
À quoi ressemble un skill communautaire typique
Les skills communautaires des quatre premières semaines se regroupent en quelques schémas utiles :
- •Wrappers d'outils CLI existants. Quelqu'un prend
ffmpeg,pandocouimagemagicket écrit un skill fin qui expose les opérations courantes — couper une vidéo, convertir un document, redimensionner une image. Peu coûteux à écrire et immédiatement utile. - •Intégrations avec des services personnels. Des skills qui parlent à ton compte Notion, ton vault Obsidian, ton instance Home Assistant, ton lecteur RSS, ton compte Pocket ou ton appli de finances perso. La plupart font moins de 200 lignes de Python plus un manifeste.
- •Assistants de domaine. Des skills taillés pour des workflows spécifiques — un lecteur de papers pour chercheurs, un résumeur de git log pour les leads techniques, un générateur de menus pour ceux qui cuisinent, un assistant maître du donjon pour les groupes de JdR.
- •Shims spécifiques à un modèle. Des skills qui ajoutent des fonctionnalités propres à un provider (headers de prompt caching, budgets de raisonnement, hooks de fine-tuning) sous forme d'outils formels de l'agent, au lieu d'exiger du code client custom.
Aucun d'entre eux n'est une killer feature à lui seul. Mis bout à bout, ils marquent le moment où Hermes a cessé d'être « un truc que Nous Research a construit » pour devenir une communauté.
La conséquence intéressante
Le jour où agentskills.io a dépassé les cent skills communautaires, quelque chose de subtil a changé dans le projet. Il n'était plus possible de décrire ce qu'est Hermes Agent en listant des fonctionnalités, parce que l'ensemble des fonctionnalités n'avait plus de bornes. Ce qu'on peut décrire, c'est la forme du truc : un agent unique, qui cause avec la plateforme de chat que tu veux, qui tire des skills à la demande, le tout sous un modèle de sécurité unifié.
Ce n'est pas une liste de features. C'est une plateforme. Et c'est pour ça que l'écosystème de skills compte plus que n'importe quelle capacité individuelle qu'il contient.