Vous venez de cloner un nouveau repo et vous voulez que l’agent en connaisse les règles dès la première minute : quelle commande déploie, comment se déroulent les vérifications de style, comment lancer les tests. Vous n’aviez jusqu’ici que deux options — entasser des skills dans un dossier global (perdus à la machine suivante) ou espérer qu’AGENTS.md couvre tout. Il existe désormais une troisième voie : les skills peuvent vivre à l’intérieur même du repo, voyager avec lui et profiter à quiconque le clone. Hermes vient de sortir cette fonctionnalité, baptisée skills de projet (project-local skills), avec un verrou de confiance intégré.

En résumé : placez un dossier de skills à la racine d’un checkout git, et les sessions Hermes démarrées dans ce repo le traitent comme le niveau de priorité le plus élevé de la hiérarchie des skills — mais par sécurité, rien ne se charge tant que vous n’avez pas explicitement fait confiance au repo (PR #88566, fusionnée le 2026-08-17).

Des skills qui vivent dans le repo : .hermes/skills/ et .agents/skills/

Ajouter des skills propres au repo, c’est juste un dossier :

myproject/
├── .hermes/skills/        # emplacement natif Hermes
│   ├── deploy.md          # runbook de déploiement
│   └── api-conventions.md # règles d'écriture des API
├── .agents/skills/        # convention multi-outils (partagée avec d'autres CLI d'agents)
│   └── review.md
└── AGENTS.md

La « racine du projet » est l’ancêtre le plus proche contenant .git — worktrees et submodules comptent. Lancez Hermes depuis n’importe quel sous-dossier, et il trouvera quand même les skills du repo à la racine.

Le verrou de confiance : hermes skills trust

Les skills sont des documents de procédure exécutables que l’agent suit, alors Hermes ne charge pas aveuglément des skills provenant de repos clonés au hasard — c’est la première ligne de défense contre le prompt injection. La première fois que vous démarrez Hermes dans un repo contenant des skills de projet, le bandeau affiche un avis :

◆ 3 project skill(s) found in /home/you/myproject but not loaded — run `hermes skills trust` to enable them.

Approuvez le repo une seule fois (depuis l’intérieur, ou par chemin) :

hermes skills trust             # approuve le repo courant
hermes skills trust ~/myproject # ou explicitement
hermes skills untrust           # révoque la confiance

Les racines approuvées sont stockées dans skills.trusted_project_dirs, dans ~/.hermes/config.yaml. Pour désactiver complètement la fonctionnalité (ni scan, ni avis), passez skills.project_discovery à false :

skills:
  project_discovery: true      # activé par défaut
  trusted_project_dirs: []     # géré par trust/untrust

Priorité : projet → local → external_dirs

Les skills de projet constituent le niveau le plus haut de toute la hiérarchie : projet → local (~/.hermes/skills/) → external_dirs. Un skill nommé deploy dans le repo écrase votre skill global du même nom pour les sessions lancées dans ce repo — c’est tout l’intérêt : les skills fournis avec le repo gagnent sur leur terrain sans toucher à votre profil global. Dans l’index des skills de l’agent, les skills de projet portent le marqueur [project], pour que la provenance reste visible.

Comme les dossiers externes, les dossiers de skills de projet sont considérés comme la propriété du repo : le curator de skills autonome ne les modifie jamais, et les nouveaux skills créés par l’agent vont toujours dans ~/.hermes/skills/.

La frontière de sécurité

Le verrou de confiance est une vraie barrière de chargement, pas une décoration. Un repo non approuvé ne contribue rien à l’index des skills, à skills_list, à skill_view, aux commandes slash ni aux montages de conteneurs — sa seule surface d’exposition est l’avis d’une ligne dans le bandeau. Ce n’est qu’après l’approbation que les skills du repo entrent dans le champ de vision de l’agent.

Un dernier détail : quand l’agent tourne sur les backends Docker/Modal, les dossiers de skills de projet approuvés sont montés dans le conteneur sous un espace de noms project_skills/<idx>, avec la même isolation. AGENTS.md et les skills de projet couvrent des terrains différents : AGENTS.md dit ce qu’est ce repo ; un skill de projet dit comment se fait le travail de ce repo. Pour une vue d’ensemble des skills, voyez nos 8 skills intégrés les plus utiles et les schémas de combinaison de skills ; pour les conventions au niveau du repo, notre article sur la chaîne de répertoires AGENTS.md est un bon complément.

Quand l’utiliser

Le terrain de prédilection, ce sont les repos d’équipe : écrivez les flux de déploiement, les conventions de commit et le savoir-faire métier sous forme de skills, committez-les, et chaque membre (ou chaque exécution de CI) qui clone le repo et lance hermes skills trust une seule fois donne à son agent la même mémoire institutionnelle. Les projets personnels y gagnent aussi — rouvrir un vieux repo ne signifie plus réapprendre à l’agent depuis zéro.

La fonctionnalité est sur main — lancez hermes update et essayez-la.