Skills frameworks are everywhere. Here is what makes one worth using

Between 1 and 7 September 2026, four independent teams shipped skills systems for AI agents. OpenAI published openai/skills. Nous Research promoted Hermes Agent's skill architecture. HumanLayer open-sourced their approach. Matt Pocock's mattpocock/skills hit GitHub trending. Each was built without knowledge of the others.

That is not a coincidence. It is convergence. When the same architectural pattern shows up independently in production systems at roughly the same time, it means the problem it solves has become unavoidable. The problem: agents that start from scratch every session.

What a "skill" actually is

Strip away the branding and a skill is a modular unit of procedural knowledge that an agent can load on demand. Think of it as a function your agent can call, except the function is a block of instructions, context, and constraints rather than executable code.

A skill typically has three parts:

Trigger — when to load it. This can be explicit (the user types a command) or implicit (the agent detects that the current task matches the skill's domain).
Context — what the agent needs to know. Procedures, pitfalls, API endpoints, file paths, conventions. The stuff you would normally explain in a prompt, except it is versioned, reusable, and loadable on demand.
Execution — what the agent does with the context. Some skills are purely informational (the agent reads them and acts accordingly). Others include scripts, templates, or tool definitions.

The key insight is that a skill is not a prompt. A prompt is a one-shot instruction. A skill is a persistent, improvable module that gets better each time someone edits it. When your agent discovers a pitfall ("scp gets blocked in agent sessions, use SSH pipe instead"), that discovery goes into the skill so the next session benefits from it.

Three approaches, three trade-offs

The frameworks that shipped this month take different positions on three design questions. The answers to those questions determine what the framework is good at and where it breaks.

1. Where skills live

Hermes stores skills as markdown files in a local directory (~/.hermes/skills/). They are plain text, version-controllable, and editable in any editor. OpenAI's approach uses a structured YAML frontmatter plus markdown body, also file-based. HumanLayer takes a different route, storing skills in a managed registry with a CLI for push/pull.

File-based skills win on transparency. You can cat a skill, diff two versions, grep across all of them. Registry-based skills win on distribution. If you want to share skills across a team, a registry with versioning and access control is more practical than a shared Git repo.

The trade-off is real. Local files mean no centralised discovery. Registries mean a dependency on infrastructure you do not control. Most production deployments end up wanting both: local files for development, registry for distribution.

2. How skills are composed

A skill that works in isolation is a script. Skills that chain together are a system. The composition model is where most frameworks diverge.

Hermes uses skill references — a skill can reference another skill by name, and the agent loads both. This is simple but flat. There is no dependency graph, no conflict resolution, no way to say "load skill A, but if skill B is also loaded, use B's version of the database connection procedure."

OpenAI's model is more explicit. Skills declare their dependencies in the frontmatter, and the runtime resolves them before execution. This is more robust but adds a dependency management layer that most agent developers do not want to think about.

The practical answer is that flat composition with naming conventions beats a dependency graph for most use cases. If your skill needs a database connection, include the connection instructions in the skill itself. If two skills conflict, rename one. Dependency graphs solve a problem that most agent deployments do not have yet.

3. How skills improve

This is the question that matters most and gets discussed least. A skill that cannot improve is just a template. A skill that improves is institutional knowledge.

Hermes has the most developed answer here. Skills are patched during use — when the agent discovers a new pitfall or a better procedure, it can update the skill file directly. The skill_manage tool supports atomic patches: find the old text, replace it with new text. This creates a feedback loop where skills accumulate real-world knowledge over time.

Most other frameworks treat skills as read-only during execution. The skill is loaded, the agent follows it, and any learning stays in the session context (and evaporates when the session ends). This is the default, and it is wrong. If your agent discovers that an API endpoint changed, that discovery should flow back into the skill automatically or semi-automatically.

Architecture comparison

Dimension	Hermes Skills	OpenAI Skills	HumanLayer
Storage	Local markdown files	Local YAML + markdown	Managed registry
Trigger	Explicit command or description match	Description-based routing	Configurable hooks
Composition	Flat references by name	Declared dependencies	Registry-level resolution
Self-improvement	Yes (atomic patches during use)	No (read-only)	Partial (manual push)
Distribution	Git, Skills Hub	npm / Git	Registry CLI
Version control	Native (files on disk)	Native (files on disk)	Built into registry
Runtime overhead	Near zero (file read)	Near zero (file read)	Network call per load

Anti-patterns that kill skills

After building and using skills in production, certain patterns reliably produce bad outcomes.

The monolithic prompt skill

Some developers treat a skill as a place to dump an entire system prompt. This is a 4,000-word instruction block that the agent loads on every turn, burning context tokens and diluting attention. A skill should be surgical. If it is more than 500 words, it should probably be two skills.

The everything skill

"This skill handles deployment, testing, monitoring, and rollback." No. A skill that tries to do everything does nothing well. Split it. deploy-to-production, run-integration-tests, check-monitoring-dashboards, rollback-deployment are four skills that compose cleanly. One mega-skill with four sections is a prompt pretending to be modular.

The hardcoded tool skill

Skills that assume specific tool availability break when the environment changes. "Run docker compose up" fails if Docker is not installed. "Use gh CLI" fails if the CLI is not authenticated. Good skills check prerequisites before executing and provide fallback paths.

The read-only skill

If your skill cannot be updated during use, it is a static document, not a skill. The entire point of the pattern is that procedural knowledge accumulates. A skill that stays the same forever is a README with extra steps.

What to build on today

The protocol wars (MCP vs A2A vs NLIP) are about wire formats and transport. The skills wars are about knowledge management. They solve different layers of the same problem: making agents useful beyond a single session.

If you are starting today, the practical choice depends on your deployment model. For single-user, local-first setups (a developer and their coding agent), file-based skills with self-improvement are the clear winner. Hermes's model works here: markdown files on disk, patched during use, version-controlled with the project.

For team deployments where multiple agents share capabilities, a registry with access control makes more sense. HumanLayer's approach is closer to what you want, though the ecosystem is still immature.

For platform builders, the answer is probably both. Local files for development and iteration, registry for distribution and discovery. The agent loads skills from disk first, falls back to the registry for anything missing.

One thing is certain: the agents that ship next year will all have skills systems. The ones that do not will be starting from zero every session, and their users will notice.

Skills frameworks are everywhere. Here is what makes one worth using.