The_Portability_Problem

My fleet's handoff skill lives at ~/.claude/skills/handoff/SKILL.md. It is written in Markdown with frontmatter. It is not a Claude tool definition. It is not an OpenAI function. It is a skill - and it runs wherever the runtime can read it and follow it. That is not an accident. That is a design decision I made after the first time I realised I had written the same capability twice, in two different formats, for two different agents, and they were already starting to drift.

The portability problem is easy to miss until you add a second runtime. One agent, one provider, one tool-calling schema - there is no friction. But the moment you are running Claude Code alongside Codex or Antigravity, you have a choice: write each capability once per runtime, or find a way to write it once, period.

The Agent Skills open standard is Anthropic's answer to that choice. Announced in December 2025, its stated purpose is a universal language for agent capabilities - a format that any compliant runtime can consume, regardless of which model or provider is executing the task. With Atlassian, Figma, Notion, Canva, Stripe, and Zapier building out a partner skills directory, and Microsoft and OpenAI as early ecosystem contributors, the standard arrived with broad ecosystem backing from day one. Third-party registries - tessl.io being the most established - host 3,000+ versioned public skills and provide governance tooling layered on top of the standard. The official spec and SDK live at agentskills.io.

It is worth being precise about what this standard is not. MCP - the Model Context Protocol - addresses a different layer of the same infrastructure problem: how an agent connects to a tool server, how it exchanges context, how it retrieves the resources it needs to do work. MCP is the pipe. Agent Skills is what travels through it - named capabilities with discoverable inputs and outputs, defined in a format that survives the handoff from one runtime to another. Adjacent standards, not competing ones.

The skill layer, defined in a provider-agnostic format, is what makes the fleet's operational knowledge portable. That is the argument this article is making, and the Universal Skill Compiler is how it works in practice.

What_a_Provider-Agnostic_Skill_Definition_Looks_Like

The handoff skill is a useful example because it is genuinely cross-runtime work. Every agent in my fleet - Claude Code, Codex, Antigravity - needs to be able to hand off a session cleanly. If the skill is defined in a Claude-specific schema, the Codex version has to be maintained separately. Drift is a when, not an if.

A provider-agnostic definition looks like this:

Universal definition (provider-agnostic)

skill_id: handoff name: Session Handoff description: Write a structured session handoff for context restoration triggers: - "/handoff" - "run the handoff" inputs: - name: scope type: string description: The project scope for this handoff (e.g. "labs", "Claude") required: false outputs: - name: handoff_file type: file description: Structured markdown handoff document at the configured path preconditions: - All active tasks completed or explicitly parked - Current working directory is within the relevant project scope

No provider-specific syntax. No tool-calling envelope. The skill describes what it does, what it needs, what it produces, and under what conditions it should run. The runtime format is something the compiler handles downstream.

Here is what compiles from that single source definition for three different targets:

MCP tool definition

{ "name": "handoff", "description": "Write a structured session handoff for context restoration", "inputSchema": { "type": "object", "properties": { "scope": { "type": "string", "description": "The project scope for this handoff (e.g. \"labs\", \"Claude\")" } }, "required": [] } }

OpenAI function-calling schema

{ "type": "function", "function": { "name": "handoff", "description": "Write a structured session handoff for context restoration", "parameters": { "type": "object", "properties": { "scope": { "type": "string", "description": "The project scope for this handoff (e.g. \"labs\", \"Claude\")" } }, "required": [] } } }

LangChain tool descriptor

{ "name": "handoff", "description": "Write a structured session handoff for context restoration", "args_schema": { "scope": { "type": "str", "description": "The project scope for this handoff (e.g. 'labs', 'Claude')", "required": False } } }

Same source definition. Three runtime-specific outputs. The skill's intent is preserved - what it does, what it expects, what it returns - and only the envelope changes. That is what portability actually means in practice: not that the skill is identical in every context, but that there is one place to maintain it, and the outputs are computed rather than hand-authored.

The maintenance implication is significant. If the preconditions for the handoff skill change - say, it now requires that the AGENTS.md was read during the session - I update the source definition once, recompile, and every runtime gets the updated version automatically. Without this pattern, I would be hunting across three schema files and hoping I remembered to update all of them.

What_the_Agent_Skills_Standard_Adds

My SKILL.md system was already operating on the portability principle before the Agent Skills standard existed. The standard adds something mine does not have on its own: discoverability beyond the fleet.

Third-party registries - tessl.io being the most established - host 3,000+ versioned public skills and provide governance tooling layered on top of the standard. Skills can be published, versioned, and discovered by any compliant agent - not just the agents in my own fleet. A registered skill has a public version history: when I update and cut a new version, agents pinned to an older version keep working, agents that consume the latest get the update, and the registry handles the resolution. Inside my own fleet, I manage versioning manually; the public registry makes it automatic. That is a qualitatively different capability from what a closed, fleet-internal SKILL.md library provides.

The practical result: Agent Skills is not just about making my own fleet more maintainable. It is about making a skill genuinely reusable - across runtimes, across teams, across the ecosystem. A skill that has been published to the registry is infrastructure in a way that a private SKILL.md file is not.

None of this requires abandoning the SKILL.md format I already use. The two are compatible: SKILL.md is the authoring surface, the agent-readable definition that lives alongside the orchestration harness. The Agent Skills standard is the publishing and discovery layer that makes what lives in SKILL.md available beyond the harness. One is for running the fleet. The other is for building the ecosystem.

What_It_Means_for_Diana's_Fleet

I currently have sixteen SKILL.md files across the fleet. They all run on Claude Code. That is the entire universe in which they operate today.

The compounding arithmetic is brutal: sixteen skills across three runtimes is forty-eight definitions to maintain if I choose the manual path. Every new skill multiplies by three. Every update to a skill requires three edits, with three opportunities for the definitions to diverge. Building a compiler layer, even a lightweight one, is a longer upfront investment than rewriting a skill manually - but the payoff is that I maintain one definition instead of three.

The fleet I am running is not static. I added Antigravity as a runtime around the same time the Agent Skills standard was announced. I am not going to stop adding runtimes when a useful one becomes available. The skill layer either grows with the fleet or it becomes a bottleneck.

One source of truth. Updates propagate automatically. The skill is not fragmented across runtime definitions that can drift independently. That is the operational argument for the portable skill layer, stated plainly.

The_Investment_Case_for_the_Skill_Layer

The model cycle is real. Over the past year I have been running this fleet, the capability gap between frontier models has compressed, expanded, and compressed again. A model that was the obvious default in January is not always the obvious default in June. Provider pricing changes. Context window sizes change. New runtimes appear.

What does not change at that pace is what the fleet needs to be able to do: hand off sessions cleanly, run hygiene sweeps before merging, verify dates before writing them into files, check for untracked files before deleting directories. Those are stable capabilities. They were true before Claude Sonnet 4.6, and they will be true after whatever comes next.

If those capabilities are encoded in a portable format - if the skill layer is the durable layer - then a model migration is a runtime swap, not a capability rebuild. The skills compile to the new runtime's schema. The fleet keeps working. The operational knowledge that took months to accumulate is not lost because a provider changed their pricing.

That is the real investment case for the skill layer, and it is why "define once, run anywhere" is not a convenience feature. It is the architecture that makes the fleet's accumulated operational knowledge durable in an environment where everything else is changing.

The model is a commodity. Increasingly, multiple models can do what my fleet needs done, at similar quality, at similar price points. The skill library is not a commodity - it is the specific, accumulated, hard-won knowledge of how this fleet operates, what its preconditions are, what its outputs look like, and what happens when you skip a step. Encoding that in a portable format is what makes it an asset rather than a dependency on a single provider's continued goodwill.

That is why the skill layer earns its status. Not because SKILL.md is a clever file format, but because the skills themselves are durable in a way that prompt templates and provider-specific tool definitions are not. Write it once. Compile it anywhere. Maintain the one thing that survives the model cycle.