Ollama makes skills a native part of the local agent runtime

What changed

ollama/ollama landed agent: skills system (#17203) on its default branch. It is a substantial agent-runtime change — roughly 1,500 added lines across discovery, activation, the TUI, event handling, tests, and a bundled skill creator — rather than a README convention.

The useful details:

• SKILL.md packages are native. A skill is a directory containing a SKILL.md file with name and description frontmatter plus operating instructions. Supporting scripts and references in the directory are surfaced as resources.
• Progressive loading. Ollama puts the skill catalogue’s names and descriptions into agent context, then exposes a skill tool that loads full instructions only when needed. That avoids stuffing every workflow into the initial prompt.
• User and project scope. Discovery covers user-level .ollama/skills and .agents/skills roots, plus project-level .ollama/skills and .agents/skills. Project Ollama skills win name collisions. An environment override and XDG path are also supported.
• Explicit or model-led activation. A session can request a named skill before the first model call, while the model-facing tool can load one during a run.
• Approval semantics stay separate. Loading a skill supplies instructions; it does not grant filesystem, shell, or network permission. The tools mentioned by a skill still pass through ordinary approval rules.
• Operational plumbing is included. Skill activation emits the normal tool lifecycle events, appears in the transcript as a real tool call/result pair, validates prompt budget after injection, warns on malformed packages, supports symlinked shared skills, and adds TUI skill listing/selection.
• A bundled skill creator ships with it. Ollama installs or refreshes a native skill-creator package in the skills directory.

This is on the default branch, not yet a separate versioned release in this scan.

Commit: https://github.com/ollama/ollama/commit/573386c35eac76124ffce571f4b0fefa0a7fe13c

Why it matters

Local model runners have been climbing into the agent layer for months: tool calling, web access, shell execution, session state, and UI. Skills are the next control surface because they package how work should be done without hard-wiring every procedure into the runtime.

For Hermes and OpenClaw users, three points matter:

1. The file format is converging. Ollama accepts directory-based SKILL.md packages and even scans the generic .agents/skills location. A workflow can be maintained as an artefact rather than buried in one vendor’s system prompt.
2. Progressive disclosure is the right architecture. Keep a compact catalogue in context; load full instructions and attached resources only when selected. That saves tokens and reduces irrelevant prompt interference.
3. Instructions are not permissions. This is the important safety boundary. A skill may explain how to deploy production, but it does not bypass approval for the shell, files, or network. Agent hosts should copy that separation, not treat installed workflow text as authority.

This does not make Ollama a drop-in replacement for Hermes or OpenClaw. It makes Ollama’s own agent shell more capable and creates another consumer for portable skill packages.

My read

Worth a spike, not an immediate production migration.

The spike should test portability rather than admire the TUI:

1. Pick one low-risk Hermes/OpenClaw skill with a clear SKILL.md and a small reference file.
2. Place or symlink it under a project .agents/skills/<name>/ directory.
3. Run Ollama’s agent from a build containing 573386c with a tool-capable local model.
4. Confirm it discovers the description, loads the full instructions on demand, and can read the declared resources.
5. Include one action that needs approval and verify loading the skill does not auto-authorise it.
6. Compare behaviour and token use with the same workflow in Hermes.

Do not symlink the entire production skill estate blindly. Even if loading the text is approval-free, skills still steer models towards actions. Curate the catalogue, keep write-capable procedures explicit, and test collision precedence before sharing roots between runtimes.

Bottom line

Ollama has moved skills from convention to runtime feature: discovery, scoped precedence, on-demand loading, resources, TUI controls, event traces, and a permission boundary. That is a real signal for the agent-tooling stack. Spike one portable workflow once the commit is in a build you can pin; keep Hermes/OpenClaw as the orchestration layer until Ollama’s agent shell proves comparable on policy, scheduling, integrations, and recovery.