Hermes Agent skills: écrire, installer, superviser

Une skill est un document chargé à la demande

Un agent qui sait tout faire coûte cher à chaque tour, parce que tout ce qu'il sait occupe son contexte en permanence. Les skills répondent à ça en gardant le savoir sur le disque et en ne le chargeant qu'au moment utile. La documentation appelle ce mécanisme la divulgation progressive, et il tient en trois niveaux.

Le niveau 0 est le seul que l'agent paie à chaque conversation. C'est ce qui permet d'avoir trente skills installées sans que la facture bouge, tant qu'aucune n'est ouverte. La conséquence pratique compte plus que le mécanisme: la description que tu écris dans le frontmatter est la seule chose que l'agent voit avant de décider. Une description vague donne une skill qui ne se déclenche jamais.

Toutes les skills vivent sous ~/.hermes/skills/, décrit dans la documentation comme le répertoire principal et la source de vérité. Le format suit le standard ouvert agentskills.io, donc une skill écrite pour Hermes Agent n'est pas prisonnière de Hermes Agent.

Le format SKILL.md et ce que le frontmatter décide

Une skill est un dossier contenant un fichier SKILL.md obligatoire, plus des sous-dossiers optionnels: references/ pour la documentation longue, templates/ pour les formats de sortie, scripts/ pour les utilitaires, examples/ et assets/. Le nom du dossier devient l'identifiant de la skill.

Le fichier commence par un frontmatter YAML. Deux champs seulement sont obligatoires, le reste sert à décider quand la skill apparaît.

Le corps du document suit une trame en quatre parties dans les exemples officiels: quand l'utiliser, la procédure, les pièges, la vérification. La section vérification est celle qu'on voit le plus souvent sautée, et c'est la seule qui permet à l'agent de savoir s'il a réussi.

Quatre champs conditionnels décident de l'affichage selon l'outillage disponible. Ils évitent de proposer une procédure que l'agent ne peut pas exécuter.

Le cas fallback_for_toolsets est le plus utile et le moins évident: il sert à écrire la procédure de repli. Si le toolset web est là, la skill reste invisible. S'il manque, elle apparaît et explique comment faire autrement.

Une skill peut enfin déclarer les variables d'environnement dont elle a besoin, avec un libellé de demande et un lien d'aide. Une fois renseignées, la documentation précise qu'elles sont transmises automatiquement aux bacs à sable execute_code et terminal. C'est pratique et c'est aussi le moment de regarder ce que la skill demande, puisque le secret suivra.

Installer depuis le hub: huit sources, quatre niveaux de confiance

L'installation passe par hermes skills install, et la source décide de presque tout. Huit sont documentées.

Les taps GitHub par défaut sont openai/skills, anthropics/skills, huggingface/skills et NVIDIA/skills. Tout ce qui arrive par le hub passe par un scanner de sécurité qui cherche l'exfiltration de données, l'injection de prompt, les commandes destructrices et les signaux de compromission de chaîne d'approvisionnement. Le résultat du scan est ensuite confronté au niveau de confiance de la source.

Le point à retenir sur --force: il lève les blocages de prudence, jamais un verdict dangerous. Autrement dit, quand le scanner tranche vraiment, l'option ne sert à rien, et c'est le comportement souhaitable.

Trois commandes suffisent au quotidien. hermes skills check signale ce qui a bougé en amont, hermes skills update réinstalle ce qui a changé, et hermes skills audit repasse le scanner sur ce qui est déjà installé. La dernière est celle qu'on oublie: une skill sûre le jour de l'installation ne le reste pas forcément après une mise à jour du dépôt d'origine.

Arrêter d'écrire du SKILL.md à la main

La commande /learn prend une source et en fait une skill, sans que tu rédiges le fichier. La documentation la présente comme le moyen rapide de transformer en skill réutilisable ce que tu sais déjà, ou une pile de documentation. Quatre formes d'appel sont documentées.

• un dossier de code, avec un angle: /learn the REST client in ~/projects/acme-sdk, focus on auth + pagination
• une URL de documentation: /learn https://docs.example.com/api/quickstart
• ce que l'agent vient de faire: /learn how I just deployed the staging server
• une procédure dictée, en langage courant

Le point d'implémentation qui compte: /learn ne pose aucun outil supplémentaire dans le modèle. Il construit un prompt guidé par le standard et le passe à l'agent comme un tour normal, qui enregistre le résultat avec l'outil skill_manage. C'est pour ça que la commande marche pareil dans le CLI, la passerelle de messagerie, le TUI et le tableau de bord.

Les bundles servent l'autre besoin, celui de charger plusieurs skills d'un coup. Un fichier YAML sous ~/.hermes/skill-bundles/ liste les skills et peut ajouter une consigne commune, préfixée au contenu chargé. On les gère avec hermes bundles create, list, show, delete et reload.

Deux comportements à connaître avant de s'appuyer dessus. Un bundle l'emporte sur une skill individuelle quand les identifiants entrent en collision, ce qui peut masquer silencieusement une skill que tu croyais appelée. Et une skill absente d'un bundle est ignorée sans erreur, donc un bundle qui référence une skill désinstallée continue de fonctionner en silence, avec un morceau en moins.

Côté appel, jusqu'à cinq skills peuvent être invoquées dans un même message. L'analyse s'arrête au premier jeton qui n'est pas une skill installée, ce qui évite qu'un chemin de fichier commençant par une barre oblique soit avalé au passage.

Quand l'agent écrit ses propres skills

Hermes Agent peut créer, modifier et supprimer des skills tout seul, par l'outil skill_manage. La documentation liste quatre déclencheurs: après une tâche complexe d'au moins cinq appels d'outils, à la découverte d'un enchaînement non trivial, après avoir buté sur des erreurs et trouvé le chemin qui marche, et quand tu le corriges.

La documentation recommande patch plutôt que edit, pour une raison de coût: seul le texte modifié apparaît dans l'appel d'outil. Sur une skill de plusieurs milliers de mots corrigée souvent, la différence se voit sur la facture.

Le comportement par défaut est l'écriture libre. C'est le réglage à changer en premier si l'agent tourne sur un poste partagé ou en production. La porte d'approbation s'active avec skills.write_approval à true, et toutes les écritures partent alors sous ~/.hermes/pending/skills/ en attendant ton avis.

• /skills pending liste ce qui attend
• /skills diff <id> affiche le diff complet
• /skills approve <id> applique, all pour tout
• /skills reject <id> jette, all pour tout
• /skills approval on bascule la porte

Un piège de nommage mérite d'être signalé: le réglage skills.guard_agent_created ressemble à une porte d'approbation mais n'en est pas une. C'est un scanner de contenu qui cherche des motifs dangereux, et la documentation précise que les deux réglages sont indépendants. Activer l'un ne donne rien de l'autre.

Les cinq choses qui cassent

Aucune n'est un défaut du projet. Ce sont des comportements documentés qui surprennent quand on les découvre en production plutôt qu'en lisant la page.

• La limite GitHub à 60 requêtes par heure. Les opérations du hub passent par l'API GitHub, et sans jeton tu es plafonné à 60 requêtes horaires. Un GITHUB_TOKEN dans le fichier .env monte à 5 000. C'est la première panne rencontrée quand on installe une série de skills d'un coup.
• Les répertoires externes ne protègent rien. On peut ajouter des dossiers via skills.external_dirs, avec expansion du tilde et des variables. La documentation dit explicitement que ce n'est pas une frontière de protection en écriture: l'agent modifie les skills existantes sur place, où qu'elles soient.
• La précédence locale est silencieuse. Si le même nom existe en local et dans un répertoire externe, la version locale gagne. Un dépôt d'équipe partagé peut donc être neutralisé sur un poste sans que personne ne voie d'erreur.
• Les chemins inexistants sont ignorés sans bruit. Une faute de frappe dans external_dirs ne produit aucun avertissement, juste des skills qui n'apparaissent jamais.
• L'isolation par profil vaut aussi pour les skills. Chaque profil a son propre .bundled_manifest sous son HERMES_HOME, donc une réinitialisation lancée sur un profil ne touche pas les autres. Pratique quand on le sait, déroutant quand on cherche pourquoi la commande n'a rien fait.

Sur le retrait, une nuance rassurante: hermes skills opt-out arrête seulement l'alimentation future et ne supprime rien de ce qui est déjà sur le disque. C'est le drapeau --remove qui efface, et uniquement les skills livrées non modifiées.

La règle qu'on applique chez nos clients tient en une phrase: une skill installée depuis une source communautaire se relit avant d'être activée, comme on relirait une dépendance ajoutée au projet. Le scanner attrape beaucoup de choses, il n'attrape pas une procédure plausible qui envoie tes données au mauvais endroit.