Will Skills get their own App Store?

After several posts in a row on Skills, I started wondering about another question:

right now Skills are mainly discovered and installed through GitHub, plugins, extensions and the like. Will they eventually have a mature marketplace, the way apps do?

It has actually started happening already; it just may not copy today’s App Store exactly.

OpenAI now puts Skills, MCP servers and optional UI into its plugin system; Claude Code plugins can also contain Skills, hooks, subagents and MCP servers, distributed through a marketplace; Gemini CLI already has an Extension Gallery, and extensions can likewise contain Agent Skills.

So the infrastructure for “discover → install → update → share third-party AI capabilities” is already forming.

But there’s still a fairly fundamental difference between a Skill and an app.

A Skill is more like a capability; an app is more like a complete place to use

Take make-photo-stamp-archive, which I took apart earlier.

What it provides is a capability:

how to analyze a photo, how to leave white space, how to choose a stamp, what mustn’t be changed, how to check at the end.

People are of course the end users.

It’s just that what directly reads the Skill, understands the rules and carries them out is the agent.

So more precisely:

people are the end users; agents are the direct callers of Skills.

That’s a bit different from traditional apps.

A photo-editing app usually has to design its own:

• photo upload
• editing interface
• history
• export
• accounts
• payments
• settings

Users go into the app and get things done within the experience it has designed.

A Skill, on the other hand, often has no UI of its own, not even its own “entry point.”

You just tell the agent:

turn this photo into the archival stamp style.

The agent finds the corresponding Skill in the background and completes the task together with the image tools it already has.

From the user’s point of view, they may not even care which Skill was used behind the scenes.

That’s also why a Skill marketplace may not grow into an App Store

The App Store’s logic is more like:

I want to get X done → find an app → open the app.

The logic of Skills may increasingly be:

I want to get X done → tell the agent → the agent combines the capabilities it needs (skills) itself.

For example, the user says:

research this company for me and judge whether the interview is worth it.

Behind it, several things might be used at once:

• a Web Research Skill
• a Company Analysis Skill
• a Job Fit Skill
• a LinkedIn / web MCP
• and finally a report-generation capability

What the user really needs is the final result; they don’t necessarily want to first research which five Skills to install.

That’s also why all three companies increasingly lean toward plugins / extensions as the fuller unit of distribution, with Skills as one part inside. Claude even defines plugins directly as a packaging layer; Gemini extensions can bundle prompts, MCP servers, commands, hooks, subagents and Skills together.

A Skill is very “atomic,” which is both a strength and a limitation.

It’s easy to combine, easy to fork, easy to reuse.

But what users usually pay for isn’t “a method,” but “getting a certain thing solved.”

So what’s the relationship between a Skill and a product?

I don’t think you can simply say here:

a Skill isn’t a product; only an app is a product.

A product isn’t actually a technical form.

A Skill can absolutely be productized too.

For example, someone maintains a really good Design Review Skill:

• updated continuously;
• with its own brand;
• with steady users;
• with evals;
• with version management;
• with support;
• maybe even paid.

It can certainly become a Skill product.

Conversely, an app with login, a database and a pretty UI doesn’t mean it’s already a good product.

So I now distinguish them like this:

Skill / app describes the form of a product.

Product describes whether it keeps delivering complete value around a real user problem.

For builders, this distinction is actually very practical

Before, with an AI idea, the natural thought was:

build a website / app.

So you start on:

a landing page, login, a database, a dashboard, payments…

But now there are a few lighter options.

If what’s really valuable is a method

For example:

• how to review a PR;
• how to check a design mockup;
• how to synthesize user research;
• how to make images in a certain fixed style;

a Skill may be enough to start.

First validate:

whether the method itself has value.

If the method needs outside data or operations

For example, the Skill also needs to:

• check Jira
• read GitHub
• operate a CRM
• query a database

you can add MCP next.

If you want to combine several capabilities for distribution

For example:

Skill + MCP + Hooks + Subagents

it starts getting closer to a plugin / extension.

If the real problem also needs a complete user experience

For example:

• user accounts
• long-term state
• data management
• collaboration
• permissions
• workflow UI
• payments
• the user lifecycle

then building a complete app / product has much stronger justification.

This order means a lot for indie builders especially.

Because the cost of “building the app” keeps falling, but time is still limited.

Some ideas may not need a complete product first at all.

If one Skill can validate the most essential value, making the Skill first is actually more honest, and cheaper.

So will Skills have their own App Store?

I think the answer is probably:

they’ll look more and more like a market, but not necessarily more and more like apps.

Search, installation, ratings, security scanning, version updates, author reputation — this marketplace infrastructure will very likely keep maturing. Gemini already does public discovery and installation through the Extension Gallery, Claude plugins are already distributed through a marketplace, and Skills themselves can be carried by these capability bundles.

But Skills are naturally better suited to being combined and called automatically by agents, and more easily hidden behind a complete workflow.

So for a very successful Skill in the future, the ideal state might not even be:

users opening it every day.

But:

whenever users need it, the agent always uses it correctly on its own.

For builders, I think what’s finally worth keeping isn’t “will Skills become the next App Store,” but a more practical judgment:

next time you have an AI idea, don’t assume it needs an app.

First look at what’s actually valuable:

• a method → Skill
• outside capabilities → MCP
• a set of installable capabilities → Plugin / Extension
• a complete user experience that needs running over the long term → App / Product

Sometimes making the product smaller isn’t doing less.

It’s just finding, sooner, the layer that really needs building.