Learn Hermes Agent Advanced: Automation, Integrations & Production The Skills System: Teaching Hermes New Tricks

The Skills System: Teaching Hermes New Tricks

Advanced 🕐 22 min Lesson 4 of 16
What you'll learn
  • Distinguish memory (facts) from skills (procedures) and know when to use each
  • Explain the three-level progressive disclosure system (skills_list, skill_view, skill_view with path) and why it keeps context usage low
  • Find, inspect, and install skills from the available discovery sources
  • Use requires_toolsets and fallback_for_toolsets to control when a skill becomes visible
  • Understand how agents write their own skills and how skills.write_approval gates that
  • Group related skills into a bundle invoked by a single slash command

Memory vs. Skills

It is easy to confuse skills with the memory system from Hermes Agent Fundamentals, so start with the distinction: memory stores facts, skills store procedures. Memory might tell the agent you prefer terse commit messages. A skill tells it the exact multi-step process for deploying your specific application, every time, the same way.

Where Skills Live and the Standard They Follow

Skills are on-demand knowledge documents stored in ~/.hermes/skills/, and Hermes follows the open agentskills.io standard rather than a proprietary format -- skills built for this standard are portable beyond just Hermes.

Progressive Disclosure: Why Skills Do Not Bloat the Context

If every installed skill were loaded into the system prompt at once, having more than a handful would become expensive fast. Skills avoid this with a three-level loading system:

  • Level 0 -- skills_list() returns just metadata for every skill, around 3,000 tokens regardless of how many skills you have installed
  • Level 1 -- skill_view(name) loads the full content of one specific skill, only when it is actually relevant
  • Level 2 -- skill_view(name, path) retrieves a specific reference file within a skill, for skills with their own internal documentation

This is the same instinct as progressive subdirectory discovery for context files in Hermes Agent Fundamentals: load the cheap summary everywhere, load the expensive detail only when it is actually needed.

What a SKILL.md File Looks Like

Skills follow a standardized markdown structure with YAML frontmatter, containing name, description, version, an optional platforms field (macos, linux, windows), and a metadata.hermes section for tags, category, and conditional activation rules. The body is organized into sections: When to Use, Procedure, Pitfalls, and Verification.

Finding and Installing Skills

Skills come from several discovery sources: official skills bundled with Hermes, the public skills.sh directory, well-known endpoints (/.well-known/skills/index.json), direct GitHub repositories, and community marketplaces like ClawHub, LobeHub, and browse.sh.

hermes skills browse                    # Browse all available skills
hermes skills search <query>            # Search across sources
hermes skills inspect <identifier>      # Preview before installing
hermes skills install <identifier>      # Install with security scanning

Every installation goes through automatic security scanning for data exfiltration, prompt injection, and destructive patterns before it is added -- skills are external content, and Hermes treats them with the same scrutiny as the context files from Hermes Agent Fundamentals.

Conditional Activation

Skills can declare when they should show up at all, based on what toolsets are currently available:

  • fallback_for_toolsets -- appears only when the listed tools are not available
  • requires_toolsets -- appears only when the listed tools are available

This is what lets a skill like a DuckDuckGo search fallback automatically substitute in when a premium search tool is missing, without you manually toggling anything -- the right skill simply becomes visible or invisible depending on your actual configuration.

Agent-Managed Skills

Skills are not only something you install -- the agent creates its own as a form of procedural memory, typically after:

  • Completing a complex workflow involving five or more tool calls
  • Discovering a working path through trial and error after hitting failures
  • Being corrected by you on how something should actually be done

The available actions are create, patch, edit, delete, write_file, and remove_file. If you want oversight before any agent-written skill is committed, set skills.write_approval to require your approval first -- the same pattern used by memory's write_approval setting in Fundamentals.

Bundling Skills Together

Related skills can be grouped under a single slash command:

name: backend-dev
skills:
  - github-code-review
  - test-driven-development
  - github-pr-workflow
instruction: |
  Always start by writing failing tests, then implement.

Invoked as /backend-dev [instruction], a bundle loads every grouped skill simultaneously -- useful when a category of work always benefits from the same combination of procedures together, rather than being installed and invoked one at a time.

Adding Your Own External Skill Sources

Beyond the default location, you can point Hermes at additional directories in config.yaml:

skills:
  external_dirs:
    - ~/.agents/skills
    - /shared/team-skills

This is the mechanism that supports team-shared skill libraries -- a directory on a shared drive or synced folder that everyone's Hermes instance can read from. Local skills take precedence whenever a name conflicts with an external one.

With cron (scheduling) and skills (repeatable procedures) covered, the next lesson connects your agent to the outside world: Telegram, Discord, Slack, and the messaging gateway that ties them all together.

Key takeaways
  • Memory stores facts; skills store procedures -- this is the core distinction that determines which system a piece of knowledge belongs in
  • Progressive disclosure keeps skills_list() to ~3k tokens regardless of how many skills are installed -- full content only loads via skill_view() when a specific skill is actually relevant
  • Every skill installation is automatically scanned for data exfiltration, prompt injection, and destructive patterns before being added -- skills are treated as untrusted external content
  • Agents write their own skills after 5+ tool call workflows, error-discovered solutions, or user corrections -- skills.write_approval gates this the same way memory.write_approval gates memory writes
  • External skill directories (skills.external_dirs in config.yaml) enable shared team skill libraries -- local skills always win naming conflicts over external ones