Discovery Is Harder Than Creation in a Skill Marketplace

A developer hits a wall — their agent doesn't know how to do the specific, tedious thing they need done — and they have exactly two options. Solve it themselves, which costs an afternoon and produces a solution that works for them and nobody else. Or find someone who already solved it and bought the fix in five minutes. The entire premise of a skill marketplace is that option two should usually win. In practice, it loses constantly, and not because the skills aren't good enough — because the developer never found them.

This is the quiet failure mode of every marketplace in a young category: creation outpaces discoverability by a wide margin, because writing something is a bounded, controllable task and getting found is not. Given how low the barrier to writing a SKILL.md file is — described earlier in this series as plain markdown plus optional scripts, no schema, no build step — thousands of skills can exist covering some version of the same problem, and a buyer facing that pile has no obviously better strategy than just building their own.

Search Was Built for a Different Kind of Query

Most marketplace discovery still runs on keyword search dressed up with filters — category, tag, popularity sort — which works reasonably well when the buyer already knows the exact name of the thing they want. That's a bad assumption for skills, because the buyer usually doesn't arrive with a product name in mind. They arrive with a problem: "my agent keeps breaking my commit message format," "I need something that safely migrates a Supabase project," "I want consistent PR descriptions across a team." None of those map cleanly onto a keyword search the way "wireless mouse" maps onto a product search on a retail site.

The mismatch between how buyers actually think about their problem and how marketplace search expects them to phrase it is the single biggest tax on skill discovery today. A skill titled precisely enough to rank for the exact query a buyer types is a skill that got lucky with naming, not a skill that's necessarily the best fit. Meanwhile, a genuinely excellent skill with an imprecise or overly clever title can sit unfound for months next to five mediocre competitors that happened to use the right words.

The Category Problem Is Really a Taxonomy Problem

Skills don't sort neatly into the categories marketplaces inherited from earlier software eras — "productivity," "developer tools," "automation" — because a single skill often solves a narrow, specific problem that a broad category tells the buyer almost nothing about. A skill that generates Supabase migration runbooks and a skill that formats commit messages might both live under "developer tools," which is true and useless simultaneously.

This is a genuinely different discovery problem than the one app stores solved for consumer software, and it's worth being explicit about why the analogy breaks here — a theme the last piece in this series returns to directly. Consumer apps tend to have broad, recognizable use cases that map onto stable categories: a photo editor, a to-do list, a game. Skills tend to be narrower and more compositional — solving one specific step inside a larger workflow, meant to be combined with other skills rather than used in isolation. A taxonomy built for broad, standalone products doesn't describe a landscape of narrow, composable ones very well.

Reputation Signals Haven't Caught Up Either

Install counts and star ratings are the discovery signals every marketplace defaults to, largely because they're cheap to compute and easy to display. They're also weak signals for skills specifically, for a reason that's easy to miss: a skill can have a high install count because it solves a genuinely common problem well, or because it was the first plausible-looking result for a popular search term and got installed by people who never verified it actually worked for their case. Install count measures discoverability, which is exactly the thing being measured circularly here — it doesn't independently measure quality.

A more honest signal would be something closer to retention: does a skill get used repeatedly after the first install, or installed once and quietly abandoned when it turns out not to fit? That distinction — what actually makes a skill get reused rather than installed once and forgotten — is worth an entire piece on its own, and it's coming later in this series. But it's worth flagging here because it's specifically a discovery failure when it happens at scale: buyers keep installing skills that look good on a listing page and don't hold up in practice, because the signals available to them at decision time don't distinguish the two.

What Better Discovery Actually Requires

The honest fix isn't a better search bar — it's discovery that understands the buyer's problem rather than their phrasing, which is a fundamentally different kind of system than keyword-and-filter search. An agent-native discovery layer, where a developer describes their problem in plain language and a model maps that description onto the actual capability of available skills rather than just their listed keywords, is closer to what this category needs than another round of taxonomy tweaking. That's a genuinely harder thing to build than a search index, because it requires understanding what a skill does, not just what it says it does — which loops directly back to the verification problem covered in the previous piece. A discovery layer that actually reads and understands a skill's real behavior is doing double duty: helping buyers find the right thing, and catching the gap between a skill's description and its actual code along the way.

There's also a case for discovery that leans on composability rather than treating every skill as a standalone listing. If skills are narrow and meant to be combined, a marketplace that surfaces "developers who installed this skill also needed these three to complete the workflow" is solving the buyer's actual problem — finishing a task — rather than the narrower problem of finding one matching listing. That kind of workflow-aware recommendation doesn't exist in any mature form yet in this category, and it's a real opportunity for whichever marketplace builds it first.

Why This Determines Who Wins the Category

Creation is not the constraint in the skill economy right now, and it's unlikely to become one — the format is too easy to write in, and the incentive to package expertise, covered in the first piece of this series, is too strong. Discovery is the constraint, and it's the kind of problem that compounds: a marketplace that solves discovery well attracts more buyers, which attracts more creators competing for those buyers' attention, which makes the discovery problem harder again unless the discovery layer keeps improving in step. Whoever solves discovery in this category doesn't just win a feature war — they become the layer every other participant in the market depends on, the way a search engine ends up mattering more to a product category than any individual product listed in it.

Part of the "The Skill Economy" series on aiskill.market.