Best skills.sh Alternatives for Agent Skills in 2026

skills.sh did a lot to popularize agent skills: a public directory, a leaderboard, and a one-liner install that drops a community skill into your agent. If all you need is to browse popular public skills and try them out, it works. But the moment you ask "how do we distribute our skills to our team, privately, with versioning and some kind of review gate," the directory model runs out of road — and that is when people start searching for a skills.sh alternative.

The short answer: localskills.sh is the strongest alternative if you want a real agent skills registry — private skills, versioning with rollback, team roles, and installs that target multiple tools at once. A plain GitHub repo is the right call if you want zero new infrastructure and can live with manual installs. Directories like skillsmp, ClawHub, and Cursor Directory are useful for discovery but are closer to skills.sh than to a replacement for it. The rest of this post compares them honestly.

Why teams look for a skills.sh alternative

skills.sh is a discovery surface first. That design has real strengths — it is open, it is fast to try things, and the leaderboard tells you what the community actually uses. The gaps show up when a team tries to standardize on it:

• Everything is public. A directory built around a public leaderboard has no natural home for the skills that encode your internal conventions, architecture decisions, or deployment runbooks. Those are exactly the skills teams most want to share — and least want on the open internet.
• Installs point at community sources. You generally get whatever the author's repo contains right now. There is no publish step that freezes a version, so there is no meaningful rollback, and no diff between "what we reviewed" and "what we installed."
• No review gate. A skill is instructions your agent will follow, and often scripts your agent will execute. Installing one from a stranger's repo without review is the same trust decision as running a curl-pipe-to-bash installer. We cover what to actually check in how to security-audit a Claude skill before you install it.
• No team constructs. No organizations, no member roles, no access control, no audit trail. If your company has a platform team that curates tooling, a public directory gives them nothing to work with.

None of this is a knock on skills.sh for what it is. It is a reason to know what else exists before you standardize.

What to evaluate in an agent skills registry

Before comparing options, fix the criteria. A registry you adopt for a team should answer yes to most of these:

1. Provenance and curation. Can you tell who published a skill, and can someone in your org control which skills are approved for use?
2. Security review workflow. Is there a point in the pipeline where a human reviews skill content before it reaches every developer's machine?
3. Private and unlisted skills. Can you publish skills only your org can see?
4. Versioning and rollback. When a skill update degrades agent behavior, can you pin or roll back instead of hunting through git history?
5. Multi-tool output. Your team is rarely on one tool. Can one published skill install into Claude Code, Cursor, Windsurf, Copilot, and the rest without maintaining parallel copies?
6. Team management. Namespaces, roles, and — if you are at that scale — SSO, SCIM, and audit logs.
7. Adoption signal. Download or usage analytics, so you know which skills are actually earning their maintenance cost.

If you are still forming a mental model of what skills are and why registries exist at all, the Claude skills marketplace guide is a good primer before you weigh options.

The best skills.sh alternatives, compared honestly

1. localskills.sh — registry with private skills and team controls

localskills.sh is a full agent skills registry rather than a directory: you publish skills as versioned packages and install them into whichever tools your team uses.

What it does, concretely:

• One skill, every tool. A single published skill installs into Claude Code, Cursor, Windsurf, GitHub Copilot, Cline, Codex CLI, Aider, and more. The CLI writes each tool-native format — .cursor/rules (.mdc) for Cursor, .claude/skills/ for Claude Code, .windsurf/rules/ for Windsurf — from one source of truth, and one install can target several tools at once.
• Real packages. Every skill is a package with a root SKILL.md, and it can be a multi-file folder — docs, scripts, templates — up to 100 MB and 500 files per version.
• Versioning with rollback, plus public, private, and unlisted visibility, and built-in download analytics.
• Org structure. Folders and namespaces, teams, member roles and custom roles, and folder-level access restrictions, so the platform team can curate what the rest of the org installs.
• Enterprise plumbing where it matters: SAML SSO with setup templates for Okta, Cloudflare Access, and Authentik, SCIM directory sync, audit logs, and verified-domain auto-join.
• GitHub sync. Bidirectional mirroring of an org's skill library to a GitHub repo — edits made in the repo import back as new skill versions, so review can happen in a normal pull request.
• MCP server with OAuth and scoped access, so agents can search and install skills over MCP without a human in the loop.

Honest limits: it is a registry, so it asks you to publish rather than just point at a repo. If you never need private distribution, versioning, or team controls, that publish step is overhead a public directory does not have.

2. A GitHub repo (anthropics/skills and awesome lists)

Anthropic maintains an official skills repo, and community "awesome" lists function as a de facto claude skills directory in README form. This is the zero-infrastructure option: clone, copy the folder into .claude/skills/, done.

Good: free, fully transparent, easy to fork, and review happens naturally because you read the file before copying it.

Limits: installs are manual, there is no multi-tool translation (a Claude-format skill does not become a Cursor rule by itself), no analytics, and "versioning" means git archaeology across other people's repos. For a personal setup it is fine; as team distribution it turns into copy-paste drift fast.

3. skillsmp

skillsmp is a marketplace-style index of community Claude skills, and it is a common stop for people browsing what exists. As a discovery tool it is closer to a complement than an alternative — the breadth is the point. If what sends you looking for a skillsmp alternative is team features — private skills, roles, a review gate — you are in registry territory rather than directory territory, and the criteria in the previous section apply unchanged. Check any directory's current docs before standardizing on it; these products change quickly.

4. ClawHub

ClawHub is the community skill registry that grew out of the OpenClaw agent ecosystem. If your agents are OpenClaw-based it is the native option. If your team works in Claude Code, Cursor, or Windsurf, verify compatibility before adopting it — skills there target a different runtime, and the moderation and provenance questions from the evaluation list apply with extra force to any high-volume community registry. We dig into that ecosystem specifically in ClawHub alternatives.

5. Cursor Directory

Cursor Directory is a long-running community index of Cursor rules. It is genuinely useful if Cursor is your only tool — but that is the constraint: it is rules-shaped and Cursor-shaped. Multi-file skills with scripts and templates, or a team split across Cursor and Claude Code, put you outside what it is built for.

6. Run your own: a git repo plus scripts

Some teams skip registries entirely: one internal repo, a directory per skill, and a script that symlinks or copies files into each tool's config directory. This gives you total control and total maintenance burden. You will end up rebuilding versioning, per-tool format translation, and access control by hand — which is a reasonable trade at very small scale and an unreasonable one past a handful of engineers.

Feature table: curation, security scanning, teams, private skills

Based on public information as of July 2026 — verify against current docs before you commit, since all of these move quickly.

The pattern: directories optimize for discovery, registries optimize for distribution. Most teams eventually want both — browse publicly, distribute privately.

Migrating your skills between registries

The good news: skills are markdown-plus-files, so migration is mostly mechanical. Moving from skills.sh (or a pile of copied directories) to a registry looks like this:

1. Inventory what you actually use. Check each tool's config directory and prune anything nobody has touched in months:

ls ~/.claude/skills/ .claude/skills/ 2>/dev/null
ls .cursor/rules/ .windsurf/rules/ 2>/dev/null

2. Normalize each skill into a package. One folder per skill with a root SKILL.md (name and description in frontmatter), plus any scripts or templates alongside it. Skills that were single rules files usually just need frontmatter.

3. Publish to the new registry. With localskills:

npm install -g @localskills/cli
localskills login
cd my-skill && localskills publish

The walkthrough in publish your first skill covers frontmatter, visibility, and versioning in detail.

4. Reinstall from the registry, targeting every tool at once:

localskills install your-org/deploy-runbook --target cursor claude windsurf

5. Delete the old copies and commit. The failure mode of every migration is two sources of truth. Remove the hand-copied versions so the registry install is the only one agents see.

For a team library, connect GitHub sync afterward so the whole library mirrors to a repo and future edits flow through pull requests.

FAQ

What is the best skills.sh alternative for private team skills?

A registry with private visibility and access control. localskills.sh supports private and unlisted skills, org namespaces, member roles, and folder-level restrictions, which is the feature set the public-directory model lacks. A private GitHub repo also works if you accept manual installs and no per-tool translation.

Can I use skills.sh and another registry at the same time?

Yes, and many teams do: a public directory for discovering community skills, a registry for distributing internal ones. Just keep each installed skill owned by exactly one source so updates do not fight each other.

Do skills from one registry work in every AI coding tool?

Not automatically. The SKILL.md format is portable, but each tool reads its own config location and format. That translation is either your job (copying and reformatting by hand) or the registry's — the localskills CLI writes .cursor/rules, .claude/skills/, .windsurf/rules/, and other tool-native formats from one published skill.

Is a directory or an agent skills marketplace safer than copying from GitHub?

Neither is automatically safe. What reduces risk is a review step before installation and provenance you can trace — a publisher identity, a frozen version, and ideally a pull-request gate. Apply the checklist from the skill security audit guide regardless of where a skill comes from.

---

Ready to move your team's skills somewhere with private publishing, versioning, and one-command installs across every tool? Sign up for localskills.sh and publish your first skill in a few minutes.