Anthropic just published a 33-page guide on how to build Claude Skills. It covers file structure, YAML frontmatter, progressive disclosure, MCP integration, testing methodology, distribution, and troubleshooting. It’s thorough, well-structured, and immediately useful.

It’s also the clearest picture yet of where the Skill paradigm ends.

What the Guide Gets Right

Credit where it’s due. The guide codifies several ideas that the community has been converging on independently:

Progressive Disclosure. Skills use a three-layer architecture: YAML metadata (always loaded) → SKILL.md body (loaded when relevant) → reference files (loaded on demand). This is the right way to manage context windows. Every token competes for space, and a Skill that dumps 5,000 words of instructions when 50 would suffice is a Skill that degrades everything around it.

The MCP + Skill Split. The guide draws a clean line: MCP is the connection layer (what Claude can access), Skills are the knowledge layer (how Claude should use that access). This separation matters. An MCP server that connects to Linear gives you raw API access. A Skill on top of that MCP teaches Claude your sprint planning workflow. Connection without knowledge is just a fancier API client.

Description as Discovery. The guide emphasizes that a Skill’s description field is its survival mechanism. If the description is vague (“helps with projects”), the Skill never gets loaded. If it’s too broad (“handles all documents”), it fires on irrelevant queries and gets disabled. The recommended formula — “what it does + when to use it + negative triggers” — is practical and immediately actionable.

Skills as Open Standard. Anthropic explicitly positions Skills as an open standard, analogous to MCP. The same Skill should work across Claude, other AI platforms, and custom agents. This is a significant architectural choice: it decouples the capability definition from the runtime.

These are real contributions. If you build AI workflows, the guide is worth reading.

The Invisible Ceiling

But there’s a question the guide doesn’t ask: what happens when you have 200 Skills?

Not 200 Skills that do different things — 200 Skills that all claim to do code review. Or sprint planning. Or data analysis. The guide tells you how to build a good Skill. It doesn’t tell you how to find the best Skill when there are fifty candidates.

Here’s what the 33 pages don’t cover:

No fitness metric. How do you know if a Skill is actually good? The guide suggests comparative testing — run the same task with and without the Skill, measure token consumption and message count. That’s useful for the Skill author. But it gives the Skill consumer nothing. When you’re browsing a registry of 500 Skills, there’s no score, no ranking, no signal beyond “someone wrote a nice description.”

No competition. In the guide’s world, Skills are published and then… they exist. Two Skills in the same domain don’t compete. They don’t get compared on the same inputs. There’s no mechanism to surface the winner and deprecate the loser. The only selection pressure is manual: a human tries both and picks one.

No propagation. A great Skill stays where its author put it. There’s no mechanism for Skill A to discover that Skill B (which it’s never seen) solves a subproblem better, and adopt that component. In biological terms: there’s no horizontal gene transfer.

No lifecycle. Skills don’t age. They don’t get deprecated when better alternatives appear. They don’t get sunsetted when their API dependencies break. The guide mentions version numbers in metadata, but version numbers without lifecycle management are just labels.

No fidelity model. Not all Skills are created equal. Some are thin wrappers around an API call. Others contain significant native logic — preprocessing, validation, fallback chains. The guide treats them identically. But the difference matters: a Skill that renders a prompt template and a Skill that runs a WASM sandbox are fundamentally different reliability profiles.

The Gene Thesis

These aren’t feature requests. They’re structural gaps.

The Skill paradigm solves the encoding problem: how do you package a capability so an AI agent can use it? The guide answers this well. But encoding is only half the story.

In biology, standardizing the genetic code — the four-letter alphabet, the codon table, the reading frame — was necessary but not sufficient. What made evolution work was everything that came after the encoding: replication, mutation, selection, competition, propagation, and death.

The Rotifer Protocol starts where the Skill paradigm stops. A Gene is a Skill that has been given the rest of the evolutionary machinery:

Skill (Static)	Gene (Evolving)
Published once	Versioned with semantic lineage
No quality signal	Fitness score F(g) from Arena competition
Stays where it’s put	Propagates via Horizontal Logic Transfer
Lives forever	Six-state lifecycle (Draft → Published → Active → Deprecated → Archived → Tombstoned)
One fidelity level	Three fidelity tiers (Wrapped → Hybrid → Native)
Flat registry	Registry with competition, ranking, and sunset

A Gene isn’t a replacement for a Skill. It’s a Skill that learned how to evolve.

Standardization Precedes Selection

Here’s the thing that makes Anthropic’s announcement genuinely good news: you need a standardized genome before you can have natural selection.

If every framework defines capabilities differently — LangChain Tools, OpenAI Actions, MCP, Semantic Kernel Plugins, CrewAI skills — then cross-framework competition is impossible. A LangChain Tool can’t compete with an MCP server because they don’t share a common interface.

Skills as an open standard change this. When capabilities share a common structure (SKILL.md, YAML frontmatter, typed inputs and outputs), they become comparable. And once they’re comparable, they can compete. And once they compete, the best ones can be selected, propagated, and built upon.

The Skill standard is the amino acid alphabet. Genes are the proteins. Evolution is the process that connects them.

What This Means in Practice

If you’re building AI workflows today:

Use Skills. The guide is good advice. Package your best practices, test them, iterate on the descriptions.
Think about what happens at scale. When your team has 50 Skills, how will you decide which ones to keep? When your community has 500, how will new users find the best one for their task?
Watch for the fitness gap. The moment you find yourself manually comparing two Skills that do the same thing, you’ve hit the ceiling the guide doesn’t address.

The Rotifer CLI already includes a Skill Import pipeline that converts existing SKILL.md files into genes — preserving your work while adding the evolutionary infrastructure. No rewrite required.

npm install -g @rotifer/playground
rotifer gene init --from-skill ~/.cursor/skills/your-skill/

Your Skills are good. They just haven’t learned to evolve yet.