Before You Build a Company Marketplace for Agent Skills
The public data shows why every company skill needs an owner, a clear home, and somebody who keeps it current.
I recently had a discussion with someone who really wanted a marketplace for agent skills inside their company. The idea was simple: teams write skills, publish them in one place, and everybody can install the best ones. Add search, ratings, and a list of popular skills, and the company has its own app store for AI agents.
I was not convinced. Skills are often very close to how one person or one team works. They describe how somebody reviews code, plans a change, writes an article, debugs a failing build, or decides when a task is done. Some of these instructions apply to the whole company. Many only make sense for one team, one repository, or even one person.
I wanted to see if the public skills support that view, so I looked at skills.sh. The site has a large public list of agent skills. It shows an All Time (972,985) number and also has trending and hot lists. I wanted to know what these skills cover, who publishes them, and how much information they contain.
The first thing I noticed was that 972,985 is not the number of skills.
On July 22, 2026, the page data listed 9,573 skills for the all-time view. The separate 972985 value is used for the All Time tab, but I could not find an explanation of what it counts. The API documentation describes the total number of skill records and the install count for each skill. It does not explain this larger number.
So I used 9,573 as the total shown by the page data. I left 972,985 out of the analysis because I do not know what it measures.
What people publish
The full API needs authentication. The public pages still include the first 600 entries from each list, so I used those entries for the analysis: 600 all-time skills, 600 trending skills, and 600 hot skills.
I gave every skill one main category based on its source repository, ID, and name. Some skills could fit into several categories. For example, a frontend design skill also says something about design and content. I still needed one category per skill so I could count them in the same way.
For a narrower count of engineering skills, I included frontend, backend, cloud, data, and testing. Together, they make up 46.5% of the all-time sample. When I also include agent workflows such as planning, code review, debugging, and work with subagents, the total is 59.0%.
Coding is still a large part of the site, but it is not most of the current lists. That narrower engineering group drops to 38.7% in trending and 37.7% in hot. Agent workflows are the largest trending category at 15.7%. Workplace automation is the largest hot category at 17.3%.
People also publish skills for SEO, email, slides, video, research, calendars, design, and their own working habits. This makes sense because the skill format is simple. If people can describe an activity as a set of instructions, they can turn it into a Markdown file and call it a skill.
So which area produces the most skills? In the all-time and hot samples, it is workplace tools and automation. Agent workflows are first in trending. Frontend work is also large, but the site has already moved far beyond coding skills.
A few repositories publish many skills
The 600 skills in the all-time sample come from 88 sources. Ten sources publish 331 of them. That is 55.2% of the sample.
These are some of the largest:
coreyhaines31/marketingskills: 61 skillsmattpocock/skills: 47 skillssamber/cc-skills-golang: 43 skillsheygen-com/hyperframes: 32 skillsmicrosoft/azure-skills: 31 skillslarksuite/cliandopen.feishu.cn: 27 skills each
This changes how we should read the list. Some repositories publish one large skill. Others split the same area into many small skills. A publisher that creates many small files takes up more space in the list, even when another publisher covers the same amount of knowledge in one file.
The two Lark sources also contain the same 27 skill names under two different source IDs. The public API has an isDuplicate field, but the public page data I used did not include that field. So I did not remove copies or forks from the sample.
Install counts need some explanation too. The skills.sh FAQ says that the site uses anonymous installation data from the command-line tool. That tool can install one skill, several selected skills, or every skill in a repository with --all. The installation code sends all selected skill names in one event.
One command can add to the install count of several skills. The number tells us that the files were installed not whether somebody used them again or got a better result. Also not if it was kept after an update or removed again after a bad result.
A company could easily copy this problem. A team publishes a large pack, adds it to the standard setup, and suddenly its install count looks excellent. The number goes up, but we still do not know whether the skills helped anybody.
Most popular skills are short
I also wanted to check the feeling that many public skills are shallow. I downloaded every sixth skill from the all-time list, starting at rank 1 and ending at rank 595. Ninety-four pages returned instructions that I could measure.
The median skill had 199 words. A quarter had fewer than 126 words, and three quarters had fewer than 623. Almost 65% were under 300 words, and 71% were under 500. At the same time, 81% had at least four headings, a code block, or a numbered list.
This means that most popular skills are short and well structured.
The word count alone does not tell us whether a skill is good. A short skill can prevent one expensive mistake. A long skill can repeat documentation that the model already knows.
But the result shows how easy it is to publish another skill. Add a name and description to the YAML header, write a few headings and steps, and the repository has a new installable file. The command-line tool can even create this basic file for you.
What matters are the details behind that file. “Write tests before implementation” is a general preference. A good repository skill says which test belongs in which module, which command runs it, which shared fixture the team already uses, which old exception still exists, and which output shows that the change works.
Teams learn these details while maintaining real software. The details also change with the repository, so somebody needs to keep the skill up to date. Writing the Markdown file is easy. Finding and maintaining the right instructions takes time.
Public skills and company skills start in different places
Some skills work very well in a public list. Azure, Firebase, Expo, or a document API can publish current instructions for their products. A framework team can explain version-specific rules and common problems. A security team can publish a check that applies to many projects.
There is a clear owner for these skills, and many people need the same information. Official skills make up 28.0% of the all-time top 600 sample.
Company skills often start after an agent made a reasonable but wrong choice in one repository:
it ran Maven from the wrong module
it used the company default architecture in a service with a documented exception
it created a generic integration test where the team uses a contract fixture
it changed the code and missed the release note or migration check
it followed the public framework guide and missed the company’s wrapper around it
The new instruction work because they sit in the relevant repository. If the company moves it into a central list too early, people remove the local details so the skill can work everywhere. Then they add exceptions for other teams. After a while, the skill reads like another company wiki page with a YAML header.
Another bad example are personal preferences. They belog close to the person using that habit. One developer may want the agent to question a design before writing code. Another may want a rough prototype first. I use skills for article voice, review passes, and tutorial structure because they describe how I work. Making every preference a company rule would give us a large list and many unnecessary discussions.
Different ways of working can make sense. Repositories have different histories. Teams have different risks. People also think and work in different ways.
Give each skill a clear place to live
I am a fan of making skills easy to find, but first give them four clear places to live.
I think that the most useful company skills to stay with a repository or team because that is where the detailed knowledge lives.
A team can move a skill to the company level after it has worked in more than one repository. It should have a named owner, explain where it applies, and include a way to check the result. Moving it should also mean that somebody agrees to maintain it.
This keeps the company list small. There are other elements that might be useful to catpure for every skill. Some history (the owner/creator, the teams that used it successfully). Or some runtime data (last date somebody checked it, and usage). An old skill that nobody checked after a platform update should show a warning. That has more value for a company than stars or install totals.
Repository skills should stay next to the code. A team can update them in the same pull request that changes the build, test layout, or architecture rule. Personal skills can stay in the developer’s own agent setup. The company can pin and review external skills in the same way it handles other dependencies.
An internal portal can still help people find all of this. It is an index at best. It does not need to turn every instruction into a product.
What I took away from the numbers
skills.sh shows how quickly people found uses for skills outside coding. The popular lists contain framework guides, small tool manuals, marketing instructions, office automation, media work, design preferences, and many skills that tell agents how to use other skills.
It also shows what happens when publishing is easy. We get many small files, a few publishers with large collections, bundles that are installed together, and popularity numbers that need very careful interpretation. This may work for a public site where people want to browse and try new things that generates impressive numbers.
Inside a company, I care more about the few instructions that help an agent work correctly in a specific repository. Those instructions need the local details, a named owner, and regular updates. They often begin with one person’s habit, then become useful to a team, and only sometimes apply to the whole company.
Start by giving those skills the right place and owner. If a marketplace later helps people find them, it can be eadd it then.