The case for an open skill format

Every few months, a new coding agent shows up with its own way of extending what it can do. One calls them plugins. Another calls them tools. A third calls them capabilities and ships a proprietary manifest format to define them. The concept underneath is almost always the same: a packaged, on-demand set of instructions for doing one job well. The packaging, though, is different every time, and that difference is starting to cost real effort.

The lock-in problem nobody asked for

Say you write a genuinely good skill: a PDF extraction routine, a database migration checklist, a code review rubric tuned to your team’s standards. If you built it for one agent’s proprietary plugin system, that work doesn’t transfer. You rewrite it for the next agent your team adopts, and again for the one after that, translating the same logic into a new schema each time.

This isn’t hypothetical friction. It’s the natural outcome of treating “how an agent learns a new capability” as a vendor feature instead of a shared convention. Every proprietary format creates a small moat, and every moat taxes anyone who wants to use more than one agent, switch agents later, or avoid betting internal tooling on a single company’s roadmap.

The people who pay that tax aren’t the agent vendors. They’re the teams and individual developers writing the actual skills: the accumulated knowledge of how to do a task correctly. That knowledge deserves to outlive whichever tool happens to be popular this year.

Why plain text wins

A SKILL.md file is about as unglamorous as a format can be: YAML frontmatter with a name, a description, and an optional license, followed by a Markdown body the agent loads when it decides the skill is relevant. No binary encoding, no proprietary runtime, no compiled bundle. Just a text file.

That plainness is the entire point.

It’s human-readable without tooling. Anyone can open a SKILL.md in a plain editor and understand what it does, no special viewer or decoder required. Compare that to a packed plugin bundle that only makes sense inside its own vendor’s runtime.

It’s diff-able. Because it’s text, a code review on a skill update looks like any other code review: a clean diff showing exactly which line changed and why. Binary or heavily structured proprietary formats don’t offer that; reviewing a change means trusting a changelog instead of reading the actual delta.

It’s version-controllable. Git, and every workflow built on top of it, already knows how to store, branch, merge, and blame a Markdown file. There’s no need for a separate registry client or versioning scheme just to track how a skill evolved. The tooling that already manages your codebase manages your skills too.

It’s agent-readable by design. The format that’s easiest for a person to read and edit also happens to be the easiest for a language model to parse and reason about. There’s no translation layer between what a human wrote and what the agent understands. That alignment isn’t an accident. Markdown became the default way developers write instructions for each other long before it became a way to write instructions for a model, and an agent trained on the world’s text is already fluent in it.

What vendor-neutral actually buys you

None of this requires a single company to own the format. That’s arguably the most important property of SKILL.md: it isn’t tied to any one agent’s runtime. It’s YAML plus Markdown, both of which predate every coding agent on the market and will outlast most of them.

A vendor-neutral format lowers the cost of adoption: you don’t have to bet on which agent wins. Write the skill once, in a format no single vendor controls, and it’s readable by whichever agent you’re using this quarter and whichever one you switch to next quarter. The skill becomes an asset that belongs to you or your team, not a line item in someone else’s platform strategy.

This also changes the calculus for anyone deciding whether to invest time writing a really good skill. If the return is “works in exactly one product,” the incentive to polish and share it is weak. If the return is “works anywhere that reads SKILL.md,” the incentive flips.

Share once, run anywhere

Standardization is often framed as a bureaucratic nicety, but here it’s closer to basic infrastructure. Once a format is common enough, a few things become possible that aren’t possible when every agent invents its own.

A registry can exist at all. SkillMD works as an open, safety-reviewed registry of SKILL.md files specifically because the format is uniform enough to review, list, and search across skills from different authors, for different purposes, without a separate integration for every source. A registry built on a dozen incompatible proprietary formats would just be a dozen smaller registries wearing one name tag.

Tooling gets built once instead of per-agent. A linter that checks frontmatter, a scanner that flags risky patterns in a skill’s body, a CLI that scaffolds a new skill: all of it can target one shared shape rather than being reimplemented for every vendor’s variant.

Knowledge compounds instead of resetting. A well-written skill for reviewing pull requests, extracting structured data, or running a migration safely can be improved by anyone who uses it, the same way an open source library improves through contributions rather than private forks.

The foundation worth building on

Agents will keep multiplying. New ones will launch with new strengths, and teams will reasonably want to use more than one, or move between them as the landscape shifts. What shouldn’t have to be rebuilt every time is the accumulated, hard-won knowledge of how to do a task correctly with an agent’s help.

A plain Markdown file with a little YAML on top isn’t a flashy answer to that problem, but it’s a durable one. It’s readable by humans and models alike, it fits the version control and review habits developers already have, and it doesn’t ask anyone to bet their skills on a single company’s continued existence. That combination, more than any particular technical feature, is why an open format is the right foundation for whatever comes next.