SKILL.md files — the markdown bundles that teach Anthropic's Claude Code agent how to perform a specific task — are plain text. That fact, more than any branding decision or growth strategy, dictates what kinds of businesses can be built around distributing them. If you've ever wondered why nobody runs a "skills app store" with a 30% take rate, or why the natural shape of this market keeps drifting toward free catalogs and paid evaluation tools, the answer sits in some surprisingly old economic dynamics.
This is an essay about those dynamics. It argues that the catalog itself wants to be free, that curation is where defensible value lives, and that the moment a catalog operator starts taking money from the entities being listed, the curation collapses and the whole thing turns into a pay-to-list directory nobody trusts. We'll walk through why that's true, what it implies for anyone designing a Claude Code skill marketplace, and how earlier markets — npm, IDE plugin galleries, browser extension stores — went through the same arc.
A SKILL.md file is a YAML frontmatter block followed by markdown prose. That's it. Here's a representative shape, lightly redacted from one I shipped last quarter:
---
name: stripe-refund-triage
description: Triage refund requests against Stripe charge history
allowed-tools: [Bash, Read, Grep]
user-invokable: true
---
# Stripe refund triage
When a customer requests a refund, you should...
That artifact is roughly four kilobytes of UTF-8 text. It has no DRM, no runtime entitlement check, no callback to a licence server. The agent reads it, follows the instructions, and that's the whole loop. If you sent me a paid skill via Stripe checkout this morning, I could put it in a public gist by lunch. You could send me a cease-and-desist, but the file is already trained into half a dozen LLM crawlers and mirrored on three Cloudflare R2 buckets. The cat doesn't go back in the bag.
Compare this to the artifacts that traditional app stores distribute. An iOS app is a signed binary that only runs on hardware enrolled in Apple's provisioning system. A Steam game ships through a content-delivery network that refuses to start the executable without an active session token. Even those systems leak — every popular game gets pirated within hours of release — but the leakage is bounded by the friction of stripping the protection. The legitimate channel stays dominant because the protection is annoying enough to deter casual copying.
SKILL.md has no protection to strip. There's nothing to crack. The text is the product, and the text is, by construction, freely distributable. Any business model that depends on enforcing scarcity over the artifact is starting from a losing position. You can wrap the file in marketing language and call it a premium asset, but the moment one buyer publishes it — and someone always does — the rest of the market routes around you.
This isn't a moral claim about whether skill authors deserve to be paid. They obviously do. It's a structural claim about what kinds of payment mechanisms can survive contact with the artifact's physical properties. Plain text in a public-facing agent ecosystem behaves like plain text. The economics have to be designed around that, not against it.
The intuitive reaction to "the artifact is free" is to assume the market will be tiny — that nobody can make money, so nobody will invest in producing high-quality skills, so the catalog will be junk. The opposite has happened. There are something like seventy-six thousand publicly discoverable SKILL.md files in the wild as of mid-2026, growing by hundreds per week. Free distribution, far from killing supply, has produced a glut.
The reason is that most skill authors aren't writing skills as a business. They're writing skills as a byproduct of doing their actual job — internal tooling at companies, agents for personal workflows, demonstrations for blog posts, examples bundled with libraries. The skill is a side effect of the work, and publishing it costs essentially nothing. The marginal cost of producing one more SKILL.md, given that the author already had to write the prompt to make their own agent useful, is the time it takes to add a frontmatter block.
This dynamic flips the economic problem upside down. The scarcity isn't on the supply side; there's no shortage of skills. The scarcity is on the discovery side. If you're a developer trying to find a good skill for, say, code review on a Python codebase, you're not constrained by the existence of such skills — you're constrained by your ability to find the one that's actually well-written, kept up to date, and free of the obvious anti-patterns. Searching seventy-six thousand markdown files by hand is not a viable workflow.
What the market needs, then, is not more production. It needs filtering. It needs someone — or something — to do the work of separating the dozen genuinely useful options from the thousand near-duplicates, the five hundred abandoned experiments, the two hundred outright copies of someone else's skill with a different frontmatter, and the handful of actively-harmful prompts that would happily run rm -rf against your home directory if Claude let them.
That filtering work is real, ongoing, and expensive. It requires reading skills, evaluating them against criteria, keeping the evaluation current as authors push updates, and presenting the results in a form the user can act on. It is, in classical economic terms, a value-added service that sits on top of the free underlying commodity. And unlike the artifact itself, the filtering layer has properties that can support a paid business — which is the topic of the next section.
Let's steelman the alternative. Suppose you're a talented skill author and you want to be paid for your work. The natural impulse is to put your best skills behind a paywall — sell them individually for five or ten dollars, or bundle them into a subscription. This is the model GitHub Marketplace tried for paid actions, that the Chrome Web Store half-tried for paid extensions, that the Visual Studio Marketplace experimented with for paid plugins. Each time the pattern has played out the same way.
The buyer pays. The buyer downloads the file. The buyer now has a plain-text copy of the skill on their machine. There is no legal or technical mechanism that prevents that buyer from forwarding the file to a friend, posting it on a forum, or simply pasting it into a public GitHub repo as a contribution to an open-source project. Even if the buyer is perfectly honest, the file ends up in their backup, in their company's shared drive, in their dotfiles repo. From there, leakage is a question of time, not whether.
You can try to put licensing language at the top of the file. People do this. The text says "Licensed for internal use only, do not redistribute." The legal force of this clause against an individual buyer who shared it with their team is approximately zero — the cost of enforcing it exceeds any conceivable recovery. Against a buyer who posted it publicly, you have a takedown remedy at best, and the file has already been mirrored. The license-as-a-paywall approach is theatre.
A more sophisticated version is to host the skill on a server and serve it through a runtime token check. The user authenticates, the server returns the skill text, the agent runs it. This works for about one cycle, because the user can save the skill text the first time they receive it and never call your server again. The instant the agent has the markdown in its context window, the protection is gone. Unlike a runtime DRM scheme for an executable — where the protection is wired into the execution path and runs continuously — text-based protection has to release the text to be useful, and the moment of release is the moment of escape.
The honest version of this analysis is uncomfortable for authors who want to monetise their work directly. There isn't a clean technical mechanism for it. The skills that are genuinely paid today — the handful that exist — are paid because the author bundles them with a service ("buy my consulting engagement and I'll write skills for your stack"), or because the buyer is a corporate customer who pays as a procurement matter rather than because the technology forces them to. Direct skill-for-money transactions, where the skill is the deliverable and the buyer has no incentive to pay beyond goodwill, don't sustain themselves at scale.
The value that can be priced is not the skill, but the answer to the question "which of these seventy-six thousand skills should I actually use." That answer is not a static artifact you download once. It's a continuously-maintained evaluation that depends on knowing the catalog as a whole, applying consistent criteria across it, keeping the evaluation current as the catalog evolves, and presenting the result in a form the user can act on with confidence.
This is a different shape of product. It's not a file. It's an ongoing service. The user doesn't pay for an artifact they can copy and walk away with; they pay for access to a maintained view of a moving target. If they stop paying, they stop receiving the current view — and because the catalog moves fast (new skills land every day, old skills get updated, abandoned skills decay), a stale view loses value quickly. The renewal logic is built into the underlying dynamics, not bolted on with licensing language.
There are several mature markets that work this way. GitHub itself is the canonical example: the source code is free, the repository hosting is mostly free, but GitHub Advanced Security — the layer that scans your code continuously and tells you which dependencies have known vulnerabilities and which patterns look like injection bugs — costs real money per developer per month. The value isn't the code, which you already own. The value is the curated, continuously-updated lens on the code that turns raw text into actionable signal.
Wikipedia plays out the same way at a different scale. The encyclopedia is free, the underlying database dumps are free, and yet a thriving market exists for paid reference works derived from Wikipedia — annotated subsets for specific industries, fact-checked enterprise versions, professionally-edited compilations. The free version isn't a competitor to the paid versions; it's the substrate they're built on. Each paid product justifies itself by adding evaluation, organisation, or domain-specific lensing that the raw substrate doesn't provide.
The translation to Claude Code skills is direct. The catalog of seventy-six thousand SKILL.md files is the substrate. It's free, it's open, and it should stay that way — that's what makes the discovery problem real for everyone using it. On top of that substrate, there's room for paid products that add evaluation. A multi-signal quality score derived from structural analysis of the skill body, frontmatter depth, evidence of anti-pattern discipline, and so on, is something a careful operator can produce, maintain, and charge for. The buyer is paying for the analysis, not the file. And the analysis is something the seller can keep producing while the buyer keeps benefiting — a sustainable transaction, not a one-shot leak.
Once you accept that curation is the priceable thing, the next question is where exactly the paywall sits. The temptation, for any operator running a freemium catalog, is to put as much as possible behind the paywall in the hopes of maximising conversion pressure. This is almost always a mistake, because it breaks the underlying property that made the curation valuable in the first place.
Here's a useful test. For any feature you're considering paywalling, ask: does this feature derive its value from being applied to the whole catalog, or from being applied to a specific user's specific workflow? If the value is in the cataloguewide signal — like a quality score that lets you rank skills against each other — paywall is fine, because the user is paying for the result of work that operates on the open underlying data. If the value is in the artifact itself — like the SKILL.md text, the install command, the basic metadata — paywall breaks the catalog, because you've now hidden the underlying substrate that any honest evaluation depends on having available for comparison.
The model that actually holds together looks roughly like this:
The reason point (b) matters more than the unenforceability argument is subtle. If you paywall the catalog, your quality scores become un-auditable. A user looking at a paid "this skill scored 87/100" badge has no way to verify what the score is measuring, because they can't see the other skills it's being compared against. The paywall destroys the public corpus that gave the comparison meaning. The score becomes indistinguishable from an editorial pick — which is fine, but it's a different and much weaker product. Open data is what makes paid evaluation defensible.
The same logic applies to the install client. If the install client is free but the quality score is paid, the user can browse the open catalog, decide on their own what to install, and use the free client to do it. They've extracted real value without paying. That's not a leak; that's the catalog working as intended. The paid layer is for users who want the evaluation work done for them — the ones for whom the time cost of doing their own filtering exceeds the subscription. Everyone else gets a perfectly functional free experience. Both populations are happy, and the paid tier doesn't depend on artificially crippling the free one.
There is a much more tempting business model than "end users pay for curation," and it shows up in the deck of every catalog operator within their first six months of operation. The pitch goes: skill authors want their skills to be discovered, the catalog is the natural place for that discovery to happen, therefore the catalog should let skill authors pay for placement. Featured slots, sponsored rankings, verified author badges, a "promoted skills" carousel — any of the half-dozen variations on the theme.
The trap is that this model is immediately, structurally, irreversibly incompatible with the curation product. The instant the catalog accepts money from a listed party in exchange for visibility, the curation metric becomes suspect. A user looking at a quality score of 87/100 has to ask: is this 87 because the skill is genuinely well-structured and well-maintained, or because the author paid the catalog operator for the privilege of looking that way? Once that question exists in the user's mind, there is no answer that fully removes it, because the operator now has a financial interest in producing scores that please paying authors rather than scores that help users.
You can try to argue that "sponsored" placements are clearly labelled, that the algorithmic rankings are walled off from the sponsorship business, that the editorial firewall is independent. App stores have been trying these arguments for fifteen years. They don't survive contact with reality, because (a) the labels degrade over time as operators trade clarity for revenue, (b) the algorithmic ranking team and the ads team work at the same company with the same shareholders, and (c) users get burned by sponsored placements that didn't deserve their visibility and lose trust in the unsponsored ones by association.
The deeper problem is that the sponsorship model and the curation model are competing for the same product surface — the catalog's listing of skills — and they reward incompatible behaviours. Curation rewards the operator for surfacing the genuinely best skill regardless of who wrote it. Sponsorship rewards the operator for surfacing the skill whose author paid the most. Over time, the financial gravity of the latter erodes the discipline of the former, until the catalog becomes indistinguishable from any other directory you can pay to appear in.
This isn't a hypothetical risk. It's what happened to the App Store's search results, to product comparison sites, to the open-data layer of every supposedly-neutral marketplace where the operator monetised on both sides. The model breaks because it has to break — the incentive gradient runs the wrong way. The defence is not to invent a better firewall. The defence is to refuse the second revenue stream entirely. End users only, never the entities being aggregated.
That refusal looks like leaving money on the table in the short term. It is, in the medium term, the only thing that makes the paid curation tier defensible at all. A quality score from an operator who takes money from listed authors is worth zero. A quality score from an operator who has structurally refused that money is worth whatever the methodology can stand up to. The brand differentiation is the refusal.
Pull these threads together and the shape of a sustainable Claude Code skill catalog comes into focus. The substrate — every SKILL.md, every install command, the categorisation, the search, the open data dump — is free and stays free. The paid layer is evaluation work done on top of the free substrate by an operator who doesn't take money from the listed parties. The revenue flows in one direction: from end users, who pay for the analysis that helps them act on the free underlying data.
This model has several properties that turn out to matter at scale.
First, it's robust to artifact leakage, because the artifact was never the priced thing. A user who downloads a SKILL.md from the free catalog and shares it with a colleague hasn't done anything that costs the operator money. The operator's revenue comes from people who want the curated view of the catalog, not from people who want the artifacts the catalog points at. Sharing the artifacts is the catalog working correctly.
Second, it's resistant to the sponsorship death spiral, because there's no second revenue stream to corrupt the first. The operator can make decisions about curation methodology purely on the merits of what produces good signal for end users, without having to weigh how a methodology change would affect listing fees. The product gets to be honest, which is both the right thing and — non-coincidentally — the marketable thing.
Third, it scales. The free substrate keeps growing because skill authors keep publishing, and they keep publishing because publishing is free and their primary motivation isn't monetisation. The paid evaluation layer scales with the substrate, because more skills means more filtering value. The operator's marginal cost of evaluating one more skill is small (it's mostly automated content analysis); the marginal user value of having that skill evaluated and ranked is large. The economics improve as the catalog grows.
Fourth, it interoperates with other tools in the ecosystem. A free catalog plus a paid evaluation tier doesn't lock anyone in. If a user wants to build their own evaluation on top of the open data, nothing stops them. If a third-party tool wants to consume the public catalog and add value in some other way — a different scoring approach, a domain-specific filter, an enterprise compliance lens — that's healthy, because the underlying corpus is open. The paid tier earns its revenue by being good at its specific job, not by controlling access.
The honest test of this model is whether anyone needs to be coerced into using it. A catalog that's free at the substrate layer, with evaluation behind an honest paywall, and no sponsorship revenue, either works because users find the evaluation worth the price or doesn't work because they don't. There's no captive market. There's no walled-garden lock-in. There's no take-rate extracted from creators. The whole arrangement stands or falls on whether the paid layer creates real value for end users, which is the right question for it to stand or fall on.
None of this is unique to Claude Code skills. The same dynamics played out, in roughly the same shape, in several previous markets where the underlying artifact was easily copyable and the genuine value lived in evaluation. Looking at how those markets converged is instructive, because the convergent equilibrium tends to repeat.
The npm registry is the closest analog. Packages are plain JavaScript, freely distributable, hosted at no cost to the publisher. The catalog grew to over two million packages. Various attempts have been made over the years to monetise package distribution directly — private package hosting, paid package access — and each has settled into roughly the same place: private hosting is a real but small business serving the specific case of teams that don't want to publish internally, while the open public registry remains the substrate the entire ecosystem runs on. The companies that built durable businesses around npm — Snyk, Socket, Sonatype — make their money on evaluation: which packages have known vulnerabilities, which packages have supply-chain risk, which packages are abandoned. Free substrate, paid analysis.
The Visual Studio Marketplace went through a similar arc. Paid extensions were available as a feature for a long time, but the paid-extension market never became significant. The extensions that get paid for are the ones bundled with a service (an extension plus the SaaS backend it talks to), not standalone code packaged for sale. Meanwhile, evaluation-layer products around the marketplace — security scanning, supply-chain auditing, enterprise governance — have been viable businesses. Same pattern: the artifact resists direct monetisation, the evaluation succeeds.
Chrome's extension store followed the same path. The original paid-extension feature was deprecated in 2020 after years of underuse and persistent fraud problems. The store is now overwhelmingly free, and the evaluation work — figuring out which extensions are safe, which are abandoned, which are spyware in disguise — has migrated to third-party tools and security researchers. Google didn't try to extract a take rate; the take rate was unenforceable, and Google's actual business is elsewhere.
Stack Overflow is worth a mention even though it's not a marketplace, because it taught the same lesson at a content level. The answers were free, the platform monetised on advertising and on a paid careers product, and the moment they started visibly tilting the content surface — first toward advertisers, later toward AI training partnerships — community trust collapsed and the answer quality cratered. The catalog of answers is still there. The trust isn't. The lesson generalises: once an operator's incentives diverge from user interest, the asset built on user interest decays.
The Claude Code skill ecosystem is young enough that the equilibrium isn't fully set yet, but it has every hallmark of converging to the same place these other markets converged. The artifact is text. The supply is abundant. The bottleneck is evaluation. The honest paid product sits on top of the open substrate. The sponsorship temptation is real and structurally fatal if accepted. The operators who get this right will build durable businesses; the ones who chase placement revenue will produce directories nobody trusts and burn the credibility of the underlying corpus on the way down. The economics aren't subtle. They've shown us the answer in three previous markets. The only question is whether the next generation of catalog operators pays attention.
Found a bug or want a topic covered? Email [email protected] or open an issue via GitHub.
SKILL.md files, not affiliated with, endorsed by, or sponsored by Anthropic.