When the Skill Market study landed on arXiv on July 10, 2026, it handed software-engineering agents their first activity-centric vocabulary for decomposing work into reusable skills. The taxonomy is a real contribution. The implementation story is the problem: Claude Code skills, Cursor rules files, and MCP tool servers cannot exchange a single skill definition between them, so reuse collapses into runtime lock-in.
What does the Skill Market paper actually establish?
The Skill Market study (arXiv:2607.09065) is the first systematic attempt to treat agent skills as a first-class object of analysis rather than an emergent property of prompting. Its core move is a taxonomy: the authors collect a large corpus of skills from public repositories and marketplaces and characterize them along four axes: the activities they encapsulate, lifecycle coverage, evolution characteristics, and evaluation mechanisms. It is, in their words, the first activity-centric characterization of SE skills.
The paper stops at characterization. It flags the need for “mechanisms to encapsulate high-context SE activities into reusable skills” and for “engineering-oriented structuring,” but it does not prescribe a contract. That gap is where a precondition-based vocabulary becomes useful. A skill written as plain prose is a hint: the model may or may not apply it, and neither the model nor the human can say why. A skill with stated preconditions, meaning the conditions that must hold before the skill applies, reads closer to a function signature. A planner can check the gate before invoking, refuse cleanly when the gate fails, and report which precondition was unsatisfied. That is the difference between “the model sometimes remembers to run the linter” and “the linter skill is guaranteed to fire when its precondition holds.” Preconditions are this article’s proposed lens, not the paper’s contribution; the paper supplies the taxonomy that makes the gap visible.
How do Claude Code skills work?
A Claude Code skill is a Markdown file, conventionally SKILL.md, whose frontmatter carries metadata including a description (community writeup). At session start, only the metadata loads. The full body of the skill loads only when Claude judges it relevant to the current task, a pattern described as progressive disclosure. Its purpose is context-window economy: a repository can carry many skills without paying for all of them on every turn.
Skills can also be invoked explicitly as slash commands; the community writeup notes that what used to be called commands now lives under the skills umbrella. The distinction between a skill that fires on relevance and one that requires an explicit call matters for anything destructive: a skill that deploys, charges a card, or tears down infrastructure should require an explicit call rather than the model’s judgment.
The Plugin system bundles skills and subagents so a team can distribute them across repositories without copy-pasting Markdown. That solves intra-runtime portability: a team can version and share its skill set. It does not solve inter-runtime portability, because a Plugin is a Claude Code artifact whose schema and slash-command surface belong to that runtime alone.
How do Cursor rules and MCP servers fit?
The three systems encode the same underlying thing, workflow knowledge, in three different materials: a callable Markdown skill, a project instruction file, and a networked tool server.
Cursor’s rules are project-scoped instruction files, describing conventions, preferred libraries, and boundaries. The cached sources do not document how Cursor invokes or gates these rules, so any claim about a steering-versus-dispatch mechanism would be guessing. What is visible is the artifact type: a rules file that lives alongside the project, distinct from Claude Code’s on-demand skill or MCP’s networked tool.
MCP servers sit at the opposite end. The Model Context Protocol exposes callable tools over a defined protocol, and in production agent stacks MCP servers appear as one integration point among several, alongside CSV, SQL, and REST sources (arXiv:2607.09493). An MCP server is a process that advertises tools the agent can call, so the skill knowledge lives in server code rather than in editable Markdown. That makes MCP the only one of the three whose skills are real programs. Auditing one means auditing a binary whose internals you may not control.
| System | Artifact | Invocation | Declared tool surface |
|---|---|---|---|
| Claude Code skills | SKILL.md + frontmatter | On-demand or slash command | Not documented in cached sources |
| Cursor rules | Project instruction file | Not documented in cached sources | Not documented in cached sources |
| MCP servers | Networked tool server | Agent tool call | Yes, via tool schema |
None of the cached sources documents a precondition gate for any of the three. That absence is the point: the contract field this article proposes is not exposed consistently, or at all.
Why can’t a skill move between runtimes?
There is no interchange format, and the three runtimes disagree about what a skill even is. A Claude Code skill is a Markdown file with a frontmatter schema and an on-demand loading contract. A Cursor rule is a context file. An MCP tool is a networked procedure. None is a subset of another. You cannot take a SKILL.md, drop it into a Cursor project, and have Cursor treat it as a rule; the cached sources do not document Cursor honoring a Claude Code-style schema, and the artifact types differ at the root. You cannot take an MCP tool definition and hand it to either of the others as an editable skill, because the tool’s logic is compiled into a server.
The practical consequence is that skill authorship becomes a one-way investment. A team that builds a library of skills for Claude Code cannot reuse them in a Cursor-based workflow or expose them to an MCP-only client without rebuilding each one against the target’s model of what a skill is. The Skill Market paper’s activity and lifecycle axes are part of what a portable contract would need; preconditions are the field this article adds. None of the three runtimes currently publishes all of them in a common form.
This is where the reuse promise inverts. “Reusable agent skill” is supposed to mean written once, used widely. In the current market it means written once, used inside one runtime, then rewritten for the next. The fragmentation pushes the runtime decision upstream of the skill decision: you commit to Claude Code or Cursor or an MCP-first stack before you can justify curating skills, because the skills will not survive a migration.
What does this mean for enterprise compliance?
Fragmented skills are an audit problem before they are a productivity problem. An enterprise that lets agents touch production needs to answer three questions about any skill: what it does, when it fires, and what it is allowed to touch. Across the three runtimes those answers live in different places and different forms.
In Claude Code the answers are partly machine-readable, because a skill is a Markdown file whose frontmatter an audit can at least enumerate (community writeup). The cached sources do not confirm which frontmatter fields bound a skill’s tool reach or gate its firing, so an audit can see that a skill exists and read what it claims to do, but cannot assume a declared tool surface. In Cursor the same questions are answered only by reading rule prose, because a rule is policy text; the cached sources do not document a declared tool surface for the current schema. In an MCP deployment the questions are answered by inspecting the server, which may be a third-party binary whose internals the buyer cannot read.
The audit cost grows with the number of runtimes in use, not the number of skills. A shop that standardizes on one runtime can build one review pipeline. A shop that runs two must maintain two vocabularies of what a skill is, two ways of enumerating which skills exist, and two escalation paths when one misbehaves. Maintenance diverges the same way: a policy change narrowing which tools a class of skill may call has to be applied in different formats for each runtime in play.
For regulated workflows this is not a footnote. If an auditor asks to see every skill that can modify production data, the quality of the answer depends entirely on which runtime holds the skill and whether that runtime can enumerate it.
What would portable skill contracts require?
The minimal portable contract is the part of a skill the Skill Market paper’s taxonomy points at: an activity description, a lifecycle position, a declared tool surface, and a set of preconditions. The first two come from the paper’s axes; the tool surface is what MCP already exposes; preconditions are the field this article proposes. If those four were standardized, a skill definition could in principle be authored once and consumed by any runtime willing to honor them. Claude Code’s frontmatter already carries metadata in this shape. MCP carries a tool surface. Cursor rules carry guidance text; the cached sources do not document declared preconditions or tool surfaces for the current schema.
That gap is small enough to close and large enough to be worth not closing, depending on who you ask. A shared schema would let skill marketplaces become runtime-agnostic, which is good for buyers and uncomfortable for runtimes that profit from skill lock-in. It would also require the runtimes to agree on semantics they currently differentiate on: how invocation is gated, how context is disclosed, and what failure looks like when a precondition is not met.
The near-term outcome is more likely a generation of teams discovering, through migration pain, which fields a portable contract would need. The Skill Market paper supplies the taxonomy but not a standard, and no vendor has a clear incentive to lead on interoperability while its own skill ecosystem is the binding reason to stay. That discovery process is the paper’s quiet second contribution: it tells the field what to measure while it waits for a format nobody is rushing to ship.
Frequently Asked Questions
How do I prevent a Claude Code skill from firing automatically?
Set disable-model-invocation in the skill frontmatter. This field tells Claude Code to require an explicit slash command rather than autonomous triggering. The field exists for skills with side effects: deployments, billing charges, or infrastructure teardown should never run on model judgment alone.
Can I share Claude Code skills across repositories?
Yes, through the Plugin system. Plugins bundle skills and subagents into a distributable package that teams can install across repos without copy-pasting Markdown. This solves intra-runtime portability. It does not help with Cursor or MCP runtimes, because Plugins compile to Claude Code’s schema and command surface.
What runtime has the worst audit story for production-touching skills?
MCP servers that ship as third-party binaries. The skill definition lives in compiled code you may not control, so enumeration means inspecting a black box. A Claude Code skill is at least readable Markdown, and Cursor rules are plaintext, but an MCP server can hide what it actually does until runtime.
Does the Skill Market paper evaluate Claude Code or Cursor?
No. The paper characterizes skills from public repositories and marketplaces along four axes: activities, lifecycle coverage, evolution characteristics, and evaluation mechanisms. It stays runtime-neutral and does not endorse specific implementations. The mapping to Claude Code, Cursor, and MCP in this article applies the paper’s taxonomy after the fact.
Why would a runtime oppose a shared skill contract?
Skill lock-in is a retention mechanism. A runtime whose differentiated skill ecosystem keeps teams from switching has no incentive to make that ecosystem portable. Standardization would let skill marketplaces become runtime-agnostic, which benefits buyers but undermines the vendor’s strategic position.
