Skill is not the same thing as tool

A common beginner mistake is to see a skill and think: “this is just another capability.”
Hermes is more precise than that.

Tools are atomic capabilities.
Skills are packaged procedures.

They tell the system how to perform a class of work using the capabilities already available.

The filesystem shape matters

Hermes skills live as directories with a SKILL.md and optional supporting folders such as:

• references/
• templates/
• scripts/
• assets/

That means skills are not primarily code plugins. They are asset bundles.

Progressive disclosure is the right strategy

Hermes does not dump every skill in full into the prompt. It does this in tiers:

• skills_list returns metadata
• skill_view loads full content on demand
• supporting files can be loaded later when necessary

This is exactly how a scalable skill system should behave.
The model first learns what procedures exist, then expands only the relevant one.

Why skills are procedural memory

The best phrase in Hermes’ own framing is that skills are procedural memory.

That means they store:

• how to do a task
• what sequence to follow
• what references to consult
• what output pattern to aim for

This is different from declarative memory such as:

• user likes concise answers
• this repo uses SQLite
• the cron system stores jobs in JSON

Those are facts. Skills are recipes.

Self-improving procedure is the deeper ambition

The presence of skill_manage is important. Hermes is not content with having static skills; it wants the agent to be able to capture successful procedures into reusable assets.

That is a much more interesting direction than “remember more facts.” It points toward an agent that can improve its workflow repertoire over time.

The important architectural takeaway

Skills are strongest when they are:

• inspectable
• editable
• metadata-rich
• lazily expanded
• separate from raw code execution

Hermes gets most of that right by making skills filesystem-first procedural assets.