Where to Find Claude Skills: Marketplaces Compared

Why is there no single canonical index yet?

Skills are files. A skill can live in a repository, in a gist, in a company internal directory, or inside a plugin bundle, and nothing requires an author to register it anywhere. That is good for adoption and bad for cataloguing, because there is no manifest server that every publisher pushes to and therefore no source that can honestly claim full coverage. Every directory you look at is someone deciding what to include.

The second complication is category drift. MCP servers arrived earlier and built directories first, so several established listing sites added skills as an additional tab rather than building something skill native. The result is that browse pages sometimes blend protocol servers, plugin bundles and instruction folders under a single label, which makes counts hard to compare and occasionally makes it unclear what you are about to install.

Practically, this means you should read any listing with two questions in mind. Is this entry a skill, an MCP server, or a bundle containing both? And does the listing link to a source repository you can actually open and read before installing? A directory that answers both clearly is more useful than one with a bigger catalog and vaguer entries.

What is the official Anthropic source good for?

Anthropic publishes documentation covering what skills are, how the file format works, how discovery and loading behave, and how to author your own. This is the authoritative reference for anything structural: what belongs in the metadata, how the description influences whether a skill triggers, how supporting files are handled, and what the packaging expectations are. When a third party guide contradicts the docs, the docs win.

Anthropic also publishes example and first party skills, which are worth reading even when you do not intend to use them. They demonstrate the intended level of specificity, how to structure progressive disclosure so the always loaded portion stays small, and how to keep instructions unambiguous. Reading two or three well written examples end to end is the fastest way to stop writing bloated skills.

The honest limitation is scope. Official material is documentation and reference first, not a broad community catalog. It will not tell you which of five competing skills for the same job is best maintained, and it is not trying to. Use it to learn the format and validate claims, then go elsewhere for breadth.

How do the independent directories compare?

ClaudeSkills.info is an independent web directory focused specifically on Claude Skills, presenting them in a browsable catalog with categories. Its value is that it is skill native rather than a section bolted onto an MCP site, so the browse experience matches what you are actually looking for. The limitation common to independent directories of this kind is that inclusion and review depth are set by whoever maintains it, and it is generally not obvious from the page whether an entry has been tested or simply listed.

Agensi is an agent ecosystem directory covering skills and related agent tooling. Directories in this category are useful when you want to see skills alongside the wider agent landscape, because they surface adjacent things you might not have searched for. The trade off is exactly that breadth: when a listing spans several categories of artifact, the depth of curation per category tends to be shallower, and you should verify what type of thing an entry is before installing.

MCP Market and LobeHub both grew from the MCP server side. MCP Market is a directory of MCP servers and related agent integrations, so it is the better starting point when your gap is access to a system rather than instruction. LobeHub is a broader AI tooling ecosystem with a discovery section covering plugins, MCP servers and assistants. Both are worth knowing, but on both you should check carefully whether a given entry is a skill or a server, because the surrounding UI does not always make the distinction obvious at a glance.

Are community GitHub lists still the best source?

Community lists such as awesome-claude-skills remain one of the most practical starting points, for a structural reason rather than a quality one. The list lives in git, so you can read its history, see what was added and when, open the pull requests that added entries, and follow every link straight to source. Nothing is behind a rendering layer that hides who added what. For evaluating trust, that transparency beats a polished catalog page.

The corresponding weakness is that curation quality depends entirely on the maintainers and the pull request queue. Entries can go stale when an upstream repository is abandoned, and a link check will not tell you that a skill has quietly stopped matching current conventions. Presence on a list is a signal that someone thought it was interesting once, not that it works today. Read the linked repo, check the last commit, and skim the actual instructions.

BoilerplateHub maintains its own directory at /claude-skills sourced from awesome-claude-skills, with the entries organised into categories and made searchable. It exists because a flat README is hard to browse when you are looking for one specific job to be done. It inherits the same caveat as its source: it reflects a snapshot of a community list, so treat entries as candidates to evaluate rather than vetted recommendations, and always open the source repository before installing.

How should you actually vet a skill before installing it?

Open the source and read it. A skill is plain text plus supporting files, which makes it one of the few kinds of dependency you can fully audit in a couple of minutes. Look at what it instructs the agent to do, whether it asks to run scripts, whether it references external endpoints, and whether any of it touches credentials. Anything that wants secrets, posts data outward, or executes code you have not read deserves the same scrutiny as any other third party dependency.

Then check the description field specifically, because it determines when the skill activates. Vague descriptions cause skills to fire on unrelated tasks or never fire at all, and a poorly scoped description in a third party skill becomes your problem the moment it is installed. If the description is weak but the body is good, copy the skill into your own repo and rewrite the description to fit how you actually work.

Check maintenance signals too, and be realistic about what they tell you. A recent commit means someone is still paying attention. An open issue describing a bug you would hit means you now know about it. A repository with no activity for a long stretch is not automatically dead, since a good skill can be finished, but it does mean nobody has revisited its assumptions since the tooling around it moved on. Read the instructions and judge whether they still describe how things work.

Finally, prefer fewer skills that you have read over many you have not. Forking a useful skill and trimming it to your stack is usually better than installing it as is, because you can delete the branches that do not apply to you and shrink what loads into context. Directories are for finding candidates. The editing is where the value shows up.