Vous gérez un vault d’équipe dans /opt/brain/skills, alors vous avez dit à votre agent dans le system prompt : « crée les nouvelles skills dans /opt/brain/skills ». Il a acquiescé, puis skill_manage a quand même écrit chaque nouvelle skill dans ~/.hermes/skills/ — parce que le code de l’outil ne lit pas votre prose. Un opérateur de la communauté en a eu tellement marre qu’il a passé le répertoire de skills local en lecture seule avec chmod pour forcer l’agent à obéir ; l’erreur OS a eu le dernier mot sur le system prompt. Un correctif fusionné le 1er septembre (PR #100377) met fin à ce bras de fer pour de bon : la nouvelle clé de config skills.create_dir dirige les skills créées par l’agent vers n’importe quel répertoire de votre choix — et chaque instruction qui nomme le chemin de création, du schema de l’outil skill_manage au texte du prompt lui-même, affiche désormais votre répertoire configuré. L’outil, le prompt et la config s’accordent enfin.

Pourquoi une instruction dans le prompt ne peut pas faire ça

Le chemin de création de skill_manage était codé en dur vers le répertoire de skills local au profile (~/.hermes/skills/). Vous pouvez écrire ce que vous voulez dans un system prompt, mais l’implémentation de l’outil lit la configuration et les chemins, pas les intentions. Quand l’humain disait « mets les skills dans /opt/brain/skills » et que l’outil écrivait dans ~/.hermes/skills/, la skill était quand même créée, trouvée et utilisée — rien n’échouait bruyamment ; le décalage accumulait simplement des skills au mauvais endroit, qu’il fallait ensuite déplacer à la main. Le bidouillage du répertoire en lecture seule ne « fonctionnait » qu’en faisant échouer le chemin par défaut, ce qui est une piètre façon d’appliquer une politique.

Le correctif : une clé de config, et les instructions suivent

Ajoutez ceci à ~/.hermes/config.yaml :

skills:
  create_dir: /opt/brain/skills

Voilà toute la configuration. Maintenant :

• skill_manage crée les nouvelles skills ici — la méthode _resolve_skill_dir() de l’outil cible le répertoire configuré (elle crée le chemin avec mkdir au premier écrit, donc le répertoire n’a pas besoin d’exister encore).
• Chaque instruction qui nomme le chemin suit le mouvement. La description du schema de l’outil skill_manage, le texte du prompt et la documentation affichent tous le répertoire configuré via display_skill_create_dir() — l’agent voit donc « les nouvelles skills atterrissent dans /opt/brain/skills/ » dans sa propre documentation d’outil, et non un chemin codé en dur et périmé.
• ~ et ${VAR} sont expansés, et les chemins relatifs sont résolus par rapport à HERMES_HOME — create_dir: team-skills signifie donc $HERMES_HOME/team-skills.
• Une valeur qui se résout vers le répertoire local par défaut est traitée comme non définie (c’est déjà le comportement actuel), pour que vous ne puissiez pas configurer accidentellement le même chemin.

Découverte, confiance et le scénario lecture seule

Une skill n’est utile que si l’agent peut la retrouver. Quand skills.create_dir est défini, le répertoire est intégré à l’ordre de recherche des skills juste après le répertoire de skills local (avec déduplication contre external_dirs) — les skills créées ici sont découvertes, approuvées et patchables sur place. Le bidouillage en lecture seule qui a lancé toute cette histoire cesse aussi d’être nécessaire : avec create_dir pointé ailleurs, un répertoire de skills local en lecture seule ne bloque plus du tout la création, parce que l’outil ne le touche jamais.

Une note de précédence : les skills locales au projet approuvées (le .hermes/skills/ d’un dépôt — voir notre guide des skills projet-locales) gardent une précédence plus élevée que le répertoire local, et cela ne change pas.

Où le pointer

• Un vault d’équipe versionné dans git (/opt/brain/skills ou un sous-répertoire du dépôt) : chaque agent de la machine — et entre machines via la sync — crée dans le vault partagé, et les skills sont versionnées et relues comme du code.
• Un répertoire scratch ou de travail : gardez ~/.hermes/skills/ propre pour les skills peaufinées à la main et laissez les skills issues d’expérimentations atterrir quelque part de jetable.
• Un home multi-profile : pointez create_dir vers un emplacement partagé pour que les skills créées sous n’importe quel profile soient visibles par tous.

Statut de la release

skills.create_dir a été fusionnée le 1er septembre (PR #100377, récupérant un travail communautaire de @giwaov avec les noms de @Frosti7) et est sur main — elle est arrivée après le tag v0.21.0 (publié le 31 août), donc elle n’est pas dans v0.21.0 ; elle arrivera avec la prochaine release. Pour l’écosystème de skills au sens large, voir notre guide des 8 meilleures skills et le post sur le Skills Hub du desktop.