One Skills Repository for My Hermes Fleet

calendar Sep 19, 2026 · 4 min read · english hermes gitlab tips  ·
Share on: linkedin copy
Diagram of directly managed Hermes agents reading common and profile-specific skills from a shared Git repository
The Hermes profiles I manage directly, reading from the same private skills repository.

I have several Hermes profiles, and some of them need the same skills. Until now, that meant keeping similar copies in different profile directories. Fixing one did not fix the others, and it was easy to lose track of which version was current.

A shared skills repository

Today I created a private GitLab repository called hermes-fleet-skills. I am not going to list the actual skills here. Millions of people publish lists of agent skills every day, and I think we are already in the middle of a skills overdose. The skills themselves are not the point of this post. The point is Hermes' support for external skill directories and the structure I am using around them.

The repository is now the source of truth for the skills that I write, approve, or adapt for the fleet. The layout is deliberately simple:

1hermes-fleet-skills/
2├── skills/
3│   ├── common/
4│   ├── agent-specific/
5│   └── third-party/
6├── manifests/
7└── scripts/

common contains skills that can be useful to every agent. agent-specific is for skills that belong to one profile or one role. third-party is for skills that I have reviewed and decided to keep in the fleet. The manifests keep track of where those imported skills came from, while the scripts validate the repository before changes are accepted.

This means I can keep one common pool without pretending that every agent needs exactly the same abilities. Sentinel Prime does not need to have the same skills as a personal assistant. Megatron does not need to know about everything Optimusprime does. They can all read the common pool, and each profile can have its own extra layer.

The Hermes part

Hermes supports external skill directories through the skills.external_dirs setting. I pointed my local Hermes profile at the checkout with:

1hermes config set skills.external_dirs '["/home/papo/dev/hermes-fleet-skills/skills"]'

That setting tells Hermes where to look for skills outside its normal profile and bundled skill directories. Hermes calls this External Skill Directories, and the official documentation covers the configuration and precedence rules. The repository itself stays a normal Git checkout. I treat it as source-controlled infrastructure and make changes there deliberately, then commit them.

I keep a copy of the repository on my desktop and on Optimusprime. Each Hermes profile points to its local skills directory.

The path is local to each machine, and a profile-local skill wins if it has the same name as a shared skill. I avoid duplicate names for that reason.

After updating the repository, I start a new Hermes session or reset the current one. Hermes does not reload new skills in an already-running session.

Promoting a skill

The workflow I want to follow is now quite clear:

  1. Try a new skill in the profile where I need it.
  2. Clean it up and decide whether it is useful outside that profile.
  3. Move the approved version into skills/common or skills/agent-specific.
  4. Run the repository validation.
  5. Commit and push it to GitLab.
  6. Pull the change on the machines that need it.
  7. Start a new session or reset the affected Hermes profiles.

The important change is that a skill can graduate from being a local experiment to being part of the fleet. Once it is in the repository, I do not need to copy it manually into every profile. I update it once, review the diff, and make the new version available to the profiles that reference the shared directory.

That also gives me a much better recovery story. If I reinstall Hermes, I do not need to remember which profile had which useful skill. I clone the repository, configure skills.external_dirs, and the shared pool is back. The profiles still keep their own configuration, memory, and personality, but the reusable procedures have a proper home.

For now this is a private repository, and that is intentional. I can be a little more disciplined about provenance, testing, and secrets before deciding whether any of the skills deserve to leave my homelab.

This is a much better arrangement than hunting through twelve profile directories trying to remember which version I fixed last month. One repository, explicit ownership, and a clear path from experiment to shared fleet skill.