How to Build Custom Hermes Agent Skills: Complete UK Developer Guide (2026)
Ampliflow
Advanced AI frontier lab and business growth agency. Helping UK businesses deploy agentic AI systems.

Skills are the difference between "I asked Hermes to summarise my emails and it kind of did" and "I type `/morning-brief` in WhatsApp and the right report appears." They convert ad-hoc agent capability into repeatable, governable workflow. They follow the open agentskills.io standard, which means a skill written for Hermes also works in Claude Code and other compatible agents — your investment ports across tools. This guide covers skill anatomy, the patterns that make them reliable, governance for team use, and the real skill files we run for ourselves and UK SME clients.
Last updated: May 2026 · Covers Hermes Agent v0.13 + the agentskills.io open standard
TL;DR:
- A skill is a directory containing a
SKILL.mdfile with YAML frontmatter and markdown instructions - The description field is the trigger — write it as a "use when…" sentence with verbs users naturally type
- For dangerous skills (send messages, modify data, deploy), set
disable-model-invocation: trueso the user must explicitly invoke - Skills follow the agentskills.io open standard — portable across Hermes, Claude Code, and other compatible agents
- Real production patterns from Ampliflow's Hermes deployment included throughout
What a Hermes skill actually is
A directory. With a `SKILL.md` file inside. With YAML frontmatter on top and markdown instructions below. That's the entire format.
` ~/.hermes/skills/morning-brief/ ├── SKILL.md # Required — the entry point ├── examples/ │ └── sample-output.md # Optional — format reference └── scripts/ └── pull-data.py # Optional — executable Hermes can invoke `
The directory name becomes the skill name (/morning-brief invokes it). The SKILL.md is where the work lives.
A minimal example:
`yaml
name: morning-brief description: Pulls overnight order data, calendar, and support queue; sends a one-paragraph WhatsApp summary. Use when the user asks for "morning brief" or schedules the agent at 08:00. disable-model-invocation: false
Process
- Pull last 24h order data from /data/orders.csv
- Pull today's calendar from Google Calendar API
- Pull open support tickets from /data/support.csv
- Synthesise into 200 words max
- Send via WhatsApp to founder's number
Format
"{N} orders overnight (£{revenue}). Today: {meeting count} meetings, {urgent count} urgent items. Support queue: {open count} open ({urgent count} urgent). Top action: {synthesised priority}."
Rules
- Lead with the most actionable item
- Flag URGENT-tagged anything in the first sentence
- Don't apologise; don't preamble; just deliver the brief
`
Roughly 25 lines of plain English. Hermes reads this, executes the steps, and delivers the WhatsApp message.
The frontmatter fields that matter
| Field | Purpose |
|---|---|
| `name` | Skill identifier; defaults to directory name |
| `description` | The most important field. Used for auto-triggering. Write as "Use when…" sentence with verbs users naturally type. |
| `disable-model-invocation` | `true` = only user can invoke. Mandatory for skills with side effects (send, modify, deploy). |
| `user-invocable` | `false` = hidden from `/` menu, only Hermes can invoke. Useful for background skills. |
| `allowed-tools` | Pre-approve specific tools without per-use prompts. |
| `paths` | Glob patterns — only activate when working on matching files. |
| `model` | Override which model runs the skill (use cheaper Haiku for reference-lookup skills). |
| `effort` | Override reasoning depth: low / medium / high / xhigh / max |
The description field is the hardest to get right. It's not documentation — it's a fuzzy-match trigger. Write it as a sentence describing when the skill should fire, leading with verbs users would naturally type. "A skill for daily reports" is bad. "Pulls overnight order data, calendar, and support queue; sends a one-paragraph WhatsApp summary. Use when the user asks for 'morning brief' or schedules the agent at 08:00" is good.
Real skill files we run in production
Skill 1 — Daily ops brief
The 25-line skill above is a real skill we run. Variations are deployed across UK SME clients with different data sources. The structural pattern (pull → synthesise → format → deliver) is reusable.
Skill 2 — Customer concierge auto-reply
`yaml
name: customer-concierge description: Auto-replies to common customer WhatsApp queries within 30 seconds using approved templates. Use when an inbound WhatsApp message is received during off-hours or for templated query types. disable-model-invocation: true allowed-tools:
- whatsapp_send
Triggers
- Inbound WhatsApp during off-hours (18:00-09:00 local)
- Inbound WhatsApp matching templated query patterns (pricing, hours, location, "is X in stock")
Process
- Match the incoming message to one of the templated patterns
- If match: send the appropriate templated response + flag the conversation for human review next morning
- If no match: send "Thanks for reaching out — our team will be back to you by 09:00 tomorrow" and flag for priority human review
Forbidden patterns (escalate to human, never auto-reply)
- Pricing for a specific custom job
- Anything containing "complaint", "refund", "cancel"
- Anything from a known VIP customer (list at /data/vip-list.txt)
- Anything mentioning legal, regulatory, or compliance terms
Templates
- See /skills/customer-concierge/templates/ for the approved response set
`
The disable-model-invocation: true is mandatory — this skill sends external messages, so only the trigger conditions or explicit user invocation should fire it. Never the agent's autonomous decision.
Skill 3 — Weekly content brief generator
`yaml
name: brief-content description: Generates a content brief for an article from a target keyword + topic cluster. Use when the user asks to "brief an article" or "create a content brief for {topic}".
Inputs
- Target keyword (e.g. "claude code pricing")
- Topic cluster (e.g. "cluster-10-claude-code")
- Target word count (default 2,500)
Process
- Pull search volume + competition from DataForSEO API for the keyword
- Pull top-3 SERP results via Exa API
- Synthesise: what do top results cover, what do they miss, what's the unique Ampliflow angle
- Generate brief at /content/briefs/{slug}.md with:
- Target keyword + variants
- Top 3 competitor URLs + their angles + their gaps
- Suggested H2 structure (5-8 sections)
- 3-5 internal links to weave in (from /content/SLUG-MAP.md)
- Recommended call-to-action
- WhatsApp confirmation: "Brief ready for {slug}, top competitor avg word count {N}"
`
This skill is what we used to brief the 23 articles in the current content authority push. Each brief is 200-300 words; the article that comes out is 2,000-3,500. The brief is the seed.
The agentskills.io open standard
Skills are portable. The agentskills.io standard means a skill written for Hermes also works (with minor adjustments) in Claude Code, Cursor, Cowork, and other compatible agents. Your investment in skill files isn't locked to one platform.
The compatibility means:
- A
SKILL.mdyou wrote for Hermes opens cleanly in Claude Code's.claude/skills/ - The frontmatter fields are the same shape
- Tool invocation patterns are similar
- Some platform-specific tools differ (Hermes has WhatsApp; Claude Code has Bash) but the skill structure is identical
For UK businesses building skill libraries, this matters for two reasons:
- No platform lock-in. If you switch from Hermes to a different agent in 18 months, your skill library mostly comes with you.
- Cross-platform team patterns. A small developer team using Claude Code on their laptops + a separate Hermes instance for ops work can share a skill library between both.
Governance patterns for team use
For team deployments, three governance patterns matter:
1. Project-level skills (committed to repo)
Commit .hermes/skills/ to your repo. Every team member working with Hermes against this repo gets the skills automatically. Updates ship via normal Git workflow.
This is the right default for skills that are repo-specific (skills that touch this codebase, this team's Slack, this team's CRM).
2. User-level skills (in ~/.hermes/skills/)
For skills that span multiple projects on a single user's machine. Useful for personal workflow patterns — "my morning brief", "my email triage". Don't share these via Git; let each team member maintain their own.
3. Org-level managed skills
For larger organisations needing centralised governance (compliance teams enforcing review checklists, security teams enforcing scan procedures), Hermes supports managed-skill deployment. Org admins push skills to all Hermes instances + can prevent users from disabling them.
This is rare for SMEs but matters for regulated UK industries (financial services, healthcare, legal) where standardisation is a compliance requirement.
4. The kill-switch pattern
Every dangerous skill should have a kill switch. The simplest: a file at /var/run/hermes-kill-switch that, when present, causes the skill to no-op + log "kill switch active." The kill switch can be touched by any team member in any incident; the skill is disabled until the file is removed.
This is how you give yourself a 60-second response to "the agent is doing something wrong" without needing to SSH in and edit configs under pressure.
The seven anti-patterns
Skills go wrong in seven recognisable ways.
- Vague description that never triggers. "A skill for reports" gives Hermes nothing to match against. Rewrite as a "Use when…" sentence.
- The mega-skill trap. Bundling weekly summary + monthly forecast + customer triage into one skill. Mega-skills load late, fire less reliably, and confuse the agent when sections conflict.
- Long procedures in `CLAUDE.md` instead of skills.
CLAUDE.mdloads every session. A 200-line procedure there costs tokens on every turn — even when you're doing unrelated work. - Over-scripting. Shipping complex Python scripts when imperative markdown instructions would work. Markdown is easier to maintain + audit.
- Wrong scope for the intended use. Putting a personal cross-project skill in
.hermes/skills/(project only) or committing a project-specific skill to~/.hermes/skills/(user-only). - Ignoring `disable-model-invocation` for dangerous skills. A
/send-customer-emailskill withoutdisable-model-invocation: truemeans Hermes can decide to fire it autonomously. Bad. - No verification step in skills with external side effects. Send actions should produce a "what would have been sent" preview before the actual send, with explicit human approval as the gate.
Frequently asked questions
How is a Hermes skill different from a Claude Code skill?
Same format (both follow agentskills.io). Same frontmatter structure. Different tool ecosystems — Hermes has WhatsApp/Telegram/Slack integration, Claude Code has Bash/file-write/Git. Most skills port between the two with minor tool-name adjustments.
Where do Hermes skills live?
Project-scoped: .hermes/skills/ in your repo (commit to Git). User-scoped: ~/.hermes/skills/ (private to your machine). Org-scoped: managed deployment for organisations needing centralised governance.
How does Hermes know which skill to invoke?
Two paths: (1) auto-trigger by matching the user's prompt against each skill's description field, or (2) explicit /skill-name invocation by the user. The description is a fuzzy-match trigger — write it precisely.
Can Hermes skills be invoked by name like Claude Code's /command?
Yes. Hermes supports the same /skill-name pattern as Claude Code. The agentskills.io standard defines this consistently across compatible agents.
How do I prevent a skill from firing autonomously?
Add disable-model-invocation: true to the frontmatter. The skill becomes user-only — the user can still invoke with /skill-name, but Hermes cannot trigger it autonomously. Mandatory for any skill with side effects.
Can skills run shell commands or external scripts?
Yes. Hermes supports the same !command` syntax as Claude Code for dynamic context injection (preprocessing — the command runs before Hermes sees the prompt). Skills can also include executable scripts in their directory and reference them via ${HERMES_SKILL_DIR}/scripts/foo.sh`.
How do I share skills with my team?
Commit .hermes/skills/ to your repo. Every team member's Hermes instance picks up the skills automatically when they pull. For cross-team distribution, package as a plugin (same pattern as Claude Code plugins).
What happens if a skill produces an error?
Hermes catches the error, logs it to the skill execution log, and either retries (if the error matches a retry pattern) or surfaces the error to the user via the appropriate channel. Skills should be designed to fail safely — produce nothing rather than produce wrong output.
How many skills should one Hermes deployment have?
Most production deployments stabilise at 8-15 active skills. Beyond ~20, the description-matching budget gets tight + Hermes' tool selection gets noisier. Curate ruthlessly.
Related reading
- ↑ What is Hermes Agent? A UK Business Guide — the foundational pillar
- ↔ Hermes Agent — Real Business Use Cases — the use cases that depend on these skill patterns
- ↔ How to Deploy Hermes Agent — UK Business Complete Guide — required before writing skills
- ↔ Hermes Agent for Content Production — uses the
brief-contentanddraft-articleskill patterns - ↔ Hermes Agent for Sales / CRM Automation — uses the customer-concierge + reactivation-queue skill patterns
- ↔ Claude Code Skills — Write, Share, Govern at Scale — the parallel concept on the Claude Code side; same agentskills.io standard
What should you do next?
Skills become valuable around the moment your team writes the second one. The first one is hardest because the patterns aren't there yet. We can help with the first three.
See Hermes-powered automations we run for clients →
Or to scope your team's first three skills: Book a free Hermes use cases review →