The Skill Marketplace Problem

I ran an audit on my Claude Code installation last week and the numbers stopped me. Seventy-one marketplaces subscribed. One hundred thirty-two plugins installed. Eight thousand nine hundred ninety-one SKILL.md files indexed. One hundred thirty-eight user-level skills authored. Twenty-six marketplaces installed but with zero plugins ever activated from them — 37% subscription waste.

That's the marketplace problem in one paragraph. The skill ecosystem grew faster than discovery did. I have more functionality available than I can possibly remember exists, and the cost of finding the right skill at the right moment has eclipsed the cost of just writing the skill myself.

This isn't theoretical. I caught myself last month writing a "summarize this PR" skill that I later discovered already existed in three of my installed plugins. I'd subscribed to the marketplaces that contained those plugins, installed them for unrelated reasons, and never realized the PR-summary capability was sitting in ~/.claude/plugins/cache/<plugin>/skills/.

The Numbers

Let me show you the actual breakdown from ~/.claude/plugins/installed_plugins.json:

{
  "marketplaces": 71,
  "marketplaces_with_active_plugins": 45,
  "marketplaces_subscribed_but_unused": 26,
  "plugins_total": 132,
  "plugins_active": 132,
  "skill_files_indexed": 8991,
  "user_skills": 138
}

The 8,991 SKILL.md count is the one that matters. That's the searchable surface. Each one declares a name, a description, a set of trigger patterns. When a session starts, Claude Code can in principle activate any of them — but in practice, the model has to pattern-match the user's phrasing against 8,991 descriptions. That's a lot of descriptions.

The way the matching actually works: Claude Code surfaces the skill descriptions to the model as a kind of menu. The model decides which to load based on the request. The match isn't perfect — descriptions that are too similar collide, descriptions that are too vague over-trigger, descriptions that don't match how users actually talk under-trigger. With 8,991 to choose from, all three failure modes get more frequent.

Why Marketplaces Accumulate

The marketplace subscription model encourages accumulation. You hear about a useful plugin, you subscribe to its marketplace to install it, you forget about the marketplace. Next time you want a different plugin from a different vendor, same pattern. The marketplaces stack up.

Of my 71 marketplaces, here's what I found in the audit:

• 0112 are official Anthropic and Vercel marketplaces — kept for trust
• 028 are from companies I've worked with — installed once for a specific task
• 0323 are from individual authors I follow — subscribed for one plugin each, mostly active
• 0428 are from authors whose names I don't recognize when I look at them

That last category is the problem. Twenty-eight marketplaces I subscribed to at some point, probably for a single plugin that solved a specific problem, now sitting in my config consuming resolution overhead. Five of those 28 still have active plugins. Twenty-three are completely dormant. The cost of a dormant marketplace is small but nonzero: it gets queried during the periodic plugin update check, its metadata gets parsed at startup, its trust profile gets evaluated. Multiply across 26 unused marketplaces and you're paying real time for nothing.

The Skill Discovery Problem

The marketplace count is just the entry point. The real cost is at the skill level. Every plugin can ship multiple skills. Some plugins ship 50+ skills. The 132 active plugins in my install collectively expose 8,991 SKILL.md files.

Here's a query I run weekly:

find ~/.claude/plugins -name "SKILL.md" -path "*/skills/*" \
    -exec sh -c '
        FILE="$1"
        DESC=$(grep -m1 "^>" "$FILE" | tr -d ">" | xargs)
        NAME=$(basename "$(dirname "$FILE")")
        echo "$NAME|$DESC"
    ' _ {} \; | sort | uniq -c | sort -rn | head -20

It finds skills with similar descriptions across plugins. The top of the output is always the same kinds of duplicates: 17 different "review-pr" skills with subtly different trigger phrasings. 12 different "explain-error" skills. 9 different "summarize" skills. Each one slightly different, each one shipped by a different plugin, all competing for the same trigger surface.

When the user types "review this PR," which of the 17 fires? The first one Claude Code resolves. The order depends on plugin install order, marketplace registration sequence, and skill name alphabetical sort. It's deterministic but unintuitive — you can't predict which skill will activate without consulting the resolution log.

The 138 User Skills

I've authored 138 skills myself. Some are wrappers around things plugins already provide, written before I realized the plugin existed. Some are project-specific. Some are duplicates of each other written in different states of memory.

The audit caught 14 user skills that overlapped with plugin skills. Of those, six were strictly worse than the plugin version (less polished, fewer trigger patterns, no validation criteria). I deleted them. Eight were specialized variants worth keeping — same general idea as the plugin, but tuned for a specific workflow.

The deletions matter because every user skill I keep is a skill I'm responsible for maintaining. The 138 number was uncomfortable until I started pruning. After three weeks of audit-driven cleanup, I'm down to 94. The trim made me faster — fewer skills to remember, less cognitive load on description lookup, fewer collisions with installed plugins.

The Discovery Overhead

Here's the practical problem: when I want to do something, I have three options. I can write a skill myself (10-30 minutes for something nontrivial). I can find an existing skill in my install (5-10 minutes of grep-ing through plugin directories). Or I can search marketplaces for a new plugin (30+ minutes including evaluation, security review, install). The economics:

The "find existing" option is consistently the cheapest, and consistently the most underused. I write skills I already have because finding them is harder than writing them. That's the discovery overhead made concrete.

The Larger Pattern

The skill marketplace problem is a specific case of a general problem in tool ecosystems: the long tail of discovery has a cost. In package managers, you see this in dependency bloat — projects with 200+ direct dependencies because every problem got solved by adding a library. In editor extensions, you see it in startup time degradation. In the Claude Code ecosystem, you see it in skill-resolution latency and accidental duplication.

The fix is the same in every case: aggressive pruning, periodic audit, and search tooling that surfaces what you already have before you reach for what's new. Pruning is unfun. Audit is unfun. Search tooling is fun to build but tedious to maintain. None of these problems get solved by waiting; they only get worse.

I run my audit monthly now. Twenty minutes. Catches the marketplaces that have gone dormant in the last 30 days, the user skills that overlap newly-installed plugins, the SKILL.md files that haven't been triggered in 90 days. The output is a delete-list. I review it, approve, and the install gets leaner.

Trust, Versioning, and What Better Looks Like

Three deeper problems sit underneath discovery. Trust: marketplaces don't carry reputation signals — a skill from an unknown author looks identical to one from a vendor I trust deeply, and SKILL.md files run with full agent permissions. Versioning: marketplaces can update SKILL.md silently, breaking trigger phrases or behavior between sessions. Telemetry: the runtime knows which skills fire and how often, but doesn't surface that data, so pruning decisions stay manual.

A minimal improvement would be three things the ecosystem doesn't yet have: usage telemetry per skill ("last triggered: 47 days ago"), trust tiers in the install manifest (vetted vs unvetted sources), and semantic search over the SKILL.md corpus. None of these require changes to the skill spec format. They're tooling problems. The ecosystem is early enough that the problems are obvious and the solutions are buildable.

“The endpoint isn't a small install. The endpoint is an install where everything in it pays its rent. 132 plugins is fine if all 132 are doing work. 71 marketplaces is fine if all 71 are trusted sources for active capabilities. The number doesn't matter; the dormancy does.”