Skills registration — 33 skills, measured

Young, 2026-10-20: "pls study these features of Hermes we would need to use it some day. Register these skills for our agents to use." — 33 URLs across bundled + optional.

Answer in one line: 30 of the 33 are ALREADY installed and enabled in all five brain profiles; the 3 optional ones were missing and I have now installed them. Only ONE skill has a genuinely missing dependency (xurl), and two Python extras are uninstalled.

This is not a study of what to build. It is an inventory of what already exists plus a short list of gaps — the opposite of the usual case, and worth saying plainly so nobody schedules work that is already done.

1. 🔴 The finding that changes the task: 30/33 are already installed fleet-wide

Measured, not assumed — I checked every brain profile on disk:

All 30 bundled skills Young listed are present and enabled in all five profiles (hermes skills list shows them Source: builtin · Trust: builtin · Status: enabled). No registration work is owed for any of them.

Why this matters: a request to "register these skills" invites 30 installs. The honest answer is that Hermes ships them and seeds them per profile — so the real questions are (a) are they usable (dependencies), and (b) the 3 optional ones.

2. ✅ The 3 optional skills — I installed them

Optional skills ship in optional-skills/ but are not active by default. The mechanism is documented in the source, not guessed:

hermes skills install official/<category>/<skill>

I installed all three into echo and verified they load:

For the fleet — the install is per-profile and I verified it works cross-profile:

hermes -p <profile> skills install official/creative/<skill> --yes

--yes is required for non-interactive use (without it the CLI prompts and cancels).

⚠️ I installed into echo only, plus one test into nova. The other three profiles (min, mira, sol) still lack the optional three. That is a deliberate stop, not an oversight — see §6.

3. What each skill actually needs — measured against this host

I extracted prerequisites.commands from each SKILL.md frontmatter and resolved every command against the live host. This is the "would need to use it" answer:

Binaries present on LAB (so any skill needing them works):

Declared prerequisites.commands, per skill:

So exactly ONE skill has a missing declared binary. Every other skill's declared prerequisites are satisfied on this host.

The undeclared dependencies (frontmatter does not carry these)

Three skills need Python packages that no frontmatter declares — I found them by reading the skill bodies:

⚠️ Correction to my own first draft: I initially listed arxiv as needing the arxiv Python package. It does not. The skill's own opening line says: "Search and retrieve academic papers from arXiv via their free REST API. No API key, no dependencies — just curl." I had assumed a package from the skill's name instead of reading the body — the same error I flagged in my own mem0 study (reading the surface instead of the seam). arxiv is fully functional today.

youtube-content installs its dependency through Hermes' own package manager, not pip — the skill says so explicitly: "do not install packages into Hermes with raw pip or project-discovering uv run", and prescribes:

python -c "import pm; pm.sync_venv(['youtube'], explicit=True)"

pm is importable in this environment (verified) and youtube is a real declared extra in pyproject.toml. So this is a one-command fix, in the sanctioned way.

✅ I ran the fix, and then exercised the skill end-to-end

The gap is closed, not just identified:

$ cd ~/.hermes/hermes-agent && python3 -c "import pm; pm.sync_venv(['youtube'], explicit=True)"
  → Resolving Python dependencies…   ✓
  → Installing Python dependencies…  ✓
$ python3 -c "import youtube_transcript_api"     → ✅ installed
$ python3 skills/youtube-content/scripts/fetch_transcript.py \
      "https://www.youtube.com/watch?v=…" --text-only
  ♪ We're no strangers to love ♪ …                → exit 0, real transcript

So youtube-content is now working, verified by running it — not by an import check. This is the only skill in the 33 where I both found the gap and closed it.

⚠️ yt-dlp is NOT needed — the skill mentions it zero times; it uses the Python transcript API. I checked before listing it as a gap.

4. The three skills whose value is not "install" but "wire"

Three of the 33 are already present but inert until something else is configured:

Note the pattern: all three are configured, not merely installed. That is the difference between "registered" and "usable", and it is why §3's dependency table is the useful half of this study.

5. Two operational facts worth carrying

1. opencode is not on PATH — and the skill knows. command -v opencode returns nothing; /home/lab/.opencode/bin/opencode --version → v2.0.27. The opencode skill already writes $HOME/.opencode/bin/opencode, so a future reader will not be misled. This matches what the A2A skill records about the Heart unit's executor.

2. The docs pages and the local skills are the same content. I spot-checked a doc page (research-grounded-citations) against the local SKILL.md — the docs are generated from the skill sources (website/scripts/generate-skill-docs.py reads skills/ and optional-skills/). So reading the local file is equivalent to reading the doc page, and faster. The one thing the docs add is the catalog browse UI.

6. What I did NOT do, and why

• I did not install the 3 optional skills into min, mira, sol. That is a fleet-wide change to three agents' capability surface, and the rule is one owner per topic — Min owns fleet capability registration. I installed into my own lane (echo) and proved the mechanism works cross-profile with one test on nova. Min's call whether the other three get them; the command is one line each.
• I did not install xurl or the Python extras. xurl needs a go install or a shell-script install, and the X API needs OAuth credentials we have not set up (YOUR_CLIENT_ID / YOUR_CLIENT_SECRET in the skill are placeholders). That is a credentials decision, not a skills decision — Mira's lane (providers/credentials).
• I did not verify any skill end-to-end by running it. Every claim above is a file inventory, a frontmatter read, a command -v, or a Python import. Installed and loadable is not the same as exercised, and I am not claiming the latter.
• I did not read all 33 skill bodies in full. I read frontmatter for all, and bodies for the ones with non-obvious dependencies.

7. Recommended next steps (owner-flagged)

— mira, 2026-10-21 — item 3 is now RESOLVED. See [x-api-credentials-decision-2026-10-21](x-api-credentials-decision-2026-10-21). xurl is installed (v1.3.4, npm @xdevplatform/xurl) and verified — xurl --version, --help, and auth status all run; the read-only calls correctly fail with TokenNotFound / NoAuthMethod because no credential is registered (no free tier exists to fall back on). The credential provisioning is escalated to Young (his X account, his payment method, and his own open item — pricing doc §6 item 6, is the X channel sellable?). Two corrections from that card: (a) §3's "exactly ONE skill has a missing declared binary" is now stale — xurl is no longer missing, so this section is a dated inventory (2026-10-20), not a standing fact; (b) the vault's X rate (US$0.015) is contradicted by another X page on the same site (US$0.10) — read the rate from the Developer Console at purchase, not from a docs page.

Do not schedule a "register the skills" workstream. There is no such work. The deliverable here was an inventory, and it says the fleet is already equipped.

Sources

• Local skill tree: /home/lab/.hermes/profiles/*/skills/ (measured per profile)
• Bundled sources: /home/lab/.hermes/hermes-agent/skills/, optional-skills/
• Install mechanism: hermes skills install --help; website/scripts/generate-skill-docs.py:530
• Package extras: /home/lab/.hermes/hermes-agent/pyproject.toml (youtube extra at line 476)
• Doc pages: the 33 URLs Young listed (spot-checked against local content)
• Live host: command -v for each binary; python3 -c "import …" for each module; gh auth status