Hermes Agent Skills: Build Custom Extensions (UK Guide 2026)
Sajad Saleem
Co-founder of Ampliflow. Builds AI automation, websites, SEO/AEO, and growth systems for UK SMEs.

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: July 2026 · Checked against Hermes Agent v0.16 and the agentskills.io open standard
TL;DR:
- A skill is a directory containing a
SKILL.mdfile with YAML frontmatter and markdown instructions - Hermes keeps its primary skill library in
~/.hermes/skills/; shared repositories can be added throughskills.external_dirs - Every installed skill can be invoked as
/skill-name, and up to five skills can be stacked in one command - Skills follow the agentskills.io open standard, but platform-specific metadata and tools still need adapting
- Real production patterns from Ampliflow's Hermes deployment included throughout
If you are looking at skills because your team needs a repeatable business workflow, the useful question is not just how to write the SKILL.md file. It is which workflow deserves automation, what needs human approval, and whether the result should live in an agent, app or dashboard. For that route, see AI automation, apps and MVP development, or book a free audit.
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.
text~/.hermes/skills/operations/morning-brief/
├── SKILL.md # Required — the entry point
├── examples/
│ └── sample-output.md # Optional — format reference
└── scripts/
└── pull-data.py # Optional — executable Hermes can invokeThe 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.
version: 1.0.0
platforms: [linux]
---
# Morning Brief
## Process
1. Pull last 24h order data from /data/orders.csv
2. Pull today's calendar from Google Calendar API
3. Pull open support tickets from /data/support.csv
4. Synthesise into 200 words max
5. 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 briefRoughly 25 lines of plain English. Hermes reads this, executes the steps, and delivers the WhatsApp message.
The frontmatter fields Hermes documents
| Field | Purpose |
|---|---|
| `name` | Skill identifier; use a short lowercase hyphenated name |
| `description` | What the skill does and when it should be used |
| `version` | Optional version for tracking changes |
| `platforms` | Optional `macos`, `linux`, or `windows` restriction |
| `metadata.hermes.tags` | Optional discovery and organisation tags |
| `metadata.hermes.category` | Optional category shown in the skill library |
| `metadata.hermes.requires_*` | Only expose the skill when required tools or toolsets are available |
| `metadata.hermes.fallback_for_*` | Expose a fallback skill when a preferred tool or toolset is unavailable |
| `metadata.hermes.config` | Declare non-secret settings Hermes should resolve from configuration |
| `required_environment_variables` | Declare secrets or environment values needed by the skill without putting them in the file |
Hermes v0.16 does not document Claude Code-specific fields such as disable-model-invocation, allowed-tools, model, or effort as Hermes skill frontmatter. Do not copy those fields across and assume they enforce permissions. Put approval rules in the procedure and keep tool permissions in Hermes configuration.
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.
version: 1.0.0
platforms: [linux]
---
# Customer Concierge Auto-Reply
## 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
1. Match the incoming message to one of the templated patterns
2. Prepare the matching response and show the exact message for approval
3. Send only after explicit approval, then flag the conversation for human review next morning
4. If no match: prepare "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 setThe approval step is the safety boundary. A skill file is guidance, not a permission system: message sending must still be constrained by the tools and approval policy available to Hermes.
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}".
---
# Generate Content Brief
## Inputs
- Target keyword (e.g. "claude code pricing")
- Topic cluster (e.g. "cluster-10-claude-code")
- Target word count (default 2,500)
## Process
1. Pull search volume + competition from DataForSEO API for the keyword
2. Pull top-3 SERP results via Exa API
3. Synthesise: what do top results cover, what do they miss, what's the unique Ampliflow angle
4. 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
5. 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
The core format is portable. Hermes follows the agentskills.io standard, so the directory, SKILL.md, name, and description carry cleanly between compatible agents. Hermes-specific metadata, platform restrictions, tool names, and approval behaviour still need checking on the destination platform. Use the official Hermes Skills System guide alongside the Agent Skills specification rather than assuming every frontmatter field is interchangeable.
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. Local Hermes skills
~/.hermes/skills/ is the primary directory and source of truth. Bundled, hub-installed, and agent-created skills all live there. Use it for personal workflows and skills owned by one Hermes profile.
2. Shared team skills through external directories
Keep shared skills in a version-controlled repository, then add that directory under skills.external_dirs in ~/.hermes/config.yaml. Hermes scans those skills alongside its local library, and a local skill with the same name takes precedence.
External directories are not read-only. If Hermes can write to the directory, agent-managed skill actions can change it. Use filesystem permissions and code review when the shared library must be controlled.
3. Skill bundles
When a workflow always needs the same set of skills, create a bundle rather than one oversized skill. Bundles live in ~/.hermes/skill-bundles/ and load several installed skills behind one slash command.
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 always-loaded context instead of skills. Keep specialised workflows on demand so they do not consume context during 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). - Treating frontmatter as a permission system. A
/send-customer-emailprocedure still needs constrained tools, a preview, and explicit approval before the external action. - 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?
The primary library is ~/.hermes/skills/. For a shared repository, add its skills directory through skills.external_dirs in ~/.hermes/config.yaml.
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 keep a skill with side effects safe?
Do not rely on an undocumented frontmatter field. Restrict the tools Hermes can use, require a preview in the procedure, and keep the external action behind explicit human approval.
Can skills run shell commands or external scripts?
Yes. Skills can include helper scripts and reference files. Execution still goes through the tools available to the current Hermes profile, so document inputs, expected output, failure handling, and verification.
How do I share skills with my team?
Keep the shared directory in Git and add it to each profile through skills.external_dirs. Use normal review and release controls for changes.
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?
There is no useful universal number. Keep each skill narrow, remove duplicates, and use bundles when several skills always travel together.
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 are not there yet.
Want help designing the first safe, repeatable workflow? Book a free Hermes use-cases review →