Ollama can now import skills from Codex, Claude and Pi

What changed

ollama/ollama has added skill imports from coding agents to its default branch. This follows Ollama’s recent introduction of native SKILL.md discovery and activation; the new change tackles migration rather than execution.

The agent TUI now accepts:

• /skills import codex from ~/.codex/skills
• /skills import claude from ~/.claude/skills
• /skills import pi from ~/.pi/agent/skills

Imported packages are copied into Ollama’s canonical skills directory and the live catalogue, tool registry and system prompt are reloaded. The command reports newly imported skills, identical packages already present, and individual failures without aborting the rest of the batch.

The defensive details are more important than the slash command:

• every candidate must be a valid skill directory with a parseable SKILL.md;
• skill names and manifest metadata are validated;
• symlinked source roots, skill directories, manifests and nested files are rejected;
• only regular files are copied;
• copying happens through a staging directory followed by a rename;
• an identical destination is left untouched;
• a destination with different contents is treated as a conflict, not overwritten.

This is a default-branch commit, not a separately versioned Ollama release in this scan.

Why it matters

Skills are starting to behave like a portable layer of agent infrastructure: small, inspectable packages that capture procedures, references and supporting scripts independently of one model or chat UI.

Ollama’s first skills implementation showed that a local runtime could discover and progressively load SKILL.md packages. This follow-up acknowledges the practical problem: useful workflows already live in other agents’ home directories, and users will not maintain four hand-copied versions forever.

The import design is sensible. Copying creates a deliberate Ollama-owned snapshot. Refusing symlinks and divergent destination content avoids two unpleasant failure modes: silently following an unexpected filesystem path, or overwriting a locally modified procedure. Reloading the catalogue immediately also makes the migration usable without restarting the agent.

For Hermes and OpenClaw, this is relevant as an ecosystem signal rather than direct integration. Neither is an accepted import source in this commit. The useful lesson is that compatible skill packages can travel, while runtime-specific permissions, tools and assumptions still need review.

My read

Worth a spike. Not an update-now event because the code has only landed on the default branch and the importer does not target Hermes or OpenClaw directly.

A useful test would take one low-risk, standards-shaped skill and run it through a supported source directory into Ollama. Check four things:

1. the instructions and attached references survive the copy;
2. re-importing identical content is idempotent;
3. changing the Ollama-side copy produces a visible conflict rather than an overwrite;
4. the workflow still asks for ordinary tool approval when it reaches an action.

Do not treat importability as semantic compatibility. A skill can parse correctly while naming tools, paths or approval behaviours that do not exist in the target runtime. Portable syntax is the easy bit; portable operating assumptions are the actual work.

The next meaningful step would be a documented neutral export/import convention, ideally based on a generic skills directory rather than an expanding list of product-specific home folders. Until then, keep one canonical source for important procedures and treat imports as generated copies.

Bottom line

Ollama has moved from merely consuming SKILL.md packages to importing them from Codex, Claude and Pi with sensible validation, staging and conflict handling. That is a concrete interoperability step for agent tooling. Spike it once it appears in a pin-able build, but do not confuse file-format convergence with full Hermes/OpenClaw compatibility.