Kamalnrf/claude-plugins: one registry resolving 63,065 skills, and two CLIs with different install targets

Two CLIs, one registry, and 63,065 skills

The project splits into two tools because the two artefact types have different hosts and different lifecycles.

claude-plugins handles Claude Code plugins: install, enable, disable and list. skills-installer handles agent skills: search, install and list, across several AI coding clients. Both are published to npm and both can be run through npx without installing anything.

The two quick start commands are:

npx claude-plugins install @EveryInc/every-marketplace/compound-engineering

npx skills-installer install @anthropics/claude-code/frontend-design

The first requires Claude Code v2.0.12 or later for plugin support, and the second carries a note to check agentskills to see whether your client supports skills at all.

The single index behind them is the part worth sizing. The registry is described as discovering 11,989 Claude Code plugins and 63,065 agent skills. That is a ratio of about five skills for every plugin, and it explains the emphasis: the skill ecosystem is where the volume is, while plugins are the smaller, more managed surface.

The naming is also split. Plugins are addressed as marketplace paths, for example @EveryInc/every-marketplace/compound-engineering. Skills are addressed as @owner/repo/name, for example @anthropics/claude-code/frontend-design. Same shape, different catalogue.

So a plugin install and a skill install look alike on the command line and land in entirely different places.

A Val Town registry, an Astro site, and a Bun CLI

One product, three runtimes, and the split is deliberate rather than accidental.

The CLI is written in Bun. The registry API runs on Val Town. The web front end at claude-plugins.dev is an Astro project. The registry itself lives at a Val Town handle for this project, and both tools call it to resolve identifiers.

That architecture has one consequence a reader should weigh. The catalogue is not a file in this repository. It is generated by crawling GitHub, held behind a hosted function, and served over the network. The repository contains the clients, not the index.

Which is why the index can be large without the repository being large. The top level is a workspace manifest, a bun lockfile, an index module, a TypeScript configuration, a patches directory, a skills directory, a packages directory holding the CLI and the web app, and agent instructions in CLAUDE.md. The registry's contents exist somewhere else entirely.

The root manifest also sets the workspace pattern to the packages directory and marks itself private, so the two published CLIs are built and released from the packages rather than from the root.

Rate limits are why the project wants your GitHub token

The scaling mechanism is stated plainly, and it is unusual enough to read carefully.

As the registry grows, the project says it is approaching the GitHub API rate limits of 5,000 requests per hour. Discovering every public plugin and skill repository means a great many GitHub calls, and one authenticated identity cannot make them indefinitely.

So there is a token pool. You authorize the project's OAuth application, the token joins a pool the maintainers rotate through to spread the load, and you can revoke it at any time from your GitHub application settings.

The scoping is what makes it reasonable rather than alarming. The grant is described as read-only access to public data only, with no access to private repositories and no actions on your behalf. Nothing you author can be read through it, and it cannot write anything.

Even so, the correct way to read this is that the index's coverage is a function of how many tokens are in the pool. A contributor adds capacity for everyone and gets nothing in return except the index they were already using, which is worth knowing before deciding.

Install is three hops from an identifier to a clone

The resolution mechanism is the same for both tools, and it is three steps.

You run the install command with an identifier in the @owner/repo/name form. The registry returns a Git repository URL. The CLI then clones it and installs the plugin or skill.

The middle step is the whole design. Nothing is proxied and no archive is mirrored: the CLI talks to GitHub directly, which means a skill is whatever its repository says it is, at the revision you fetch. The registry is a directory, not a host.

The consequence for a user is that the identifier is a lookup key rather than an artifact. A name in this index is not a package with a version and an integrity hash behind it; it resolves to a repository that can change contents under the same name. Installing or updating a skill is therefore closer to pulling a branch than to consuming a released package.

For plugins, the install target is a marketplaces directory under the Claude home. For skills, it is a skills directory, globally or in the current project. Same clone step, different destination.

Fifteen client flags in the table, fourteen in the summary

The supported client list is given twice and the two do not match.

The summary bullet names fourteen: Claude, Cursor, Windsurf, OpenCode, Codex, VS Code, Amp Code, Goose, Letta, Gemini CLI, Antigravity, Trae, Qoder and CodeBuddy.

The table below it has fifteen rows. The extra one is GitHub, with a flag of --client github, sitting between Letta and Gemini CLI. So a client is installable that the feature list does not claim.

That is worth knowing because the flag is the interface. Every other row pairs a client with a flag value, Claude Code being the default, and a reader working from the bullet alone would not know that github is a valid target.

The default matters on its own. With no --client flag, a skill installs for claude-code, which means the zero-configuration path only works for Claude Code and every other client is an explicit choice.

Plugins land in marketplaces, skills land in skills

The two install targets are laid out separately, and it is worth being precise about the paths because a skill installed globally and a skill installed locally behave differently in a project.

Plugins are installed to ~/.claude/plugins/marketplaces/, which is Claude Code's own marketplace directory. The CLI treats a plugin as something it can also disable and re-enable by name, so it is managing state that Claude Code reads, not just copying a folder.

Skills are installed to ~/.claude/skills/ when installing globally, or to ./.claude/skills/ in the current directory when the --local or -l flag is used. The local option is the one to reach for when a skill should travel with a repository rather than with your user account.

There is a third path for discovery, which is interactive rather than a destination. The search command opens an interactive terminal experience where you can search, browse, sort by relevance, stars or installs, and install without leaving the terminal.

Note that the sort keys include installs as well as stars, which is a popularity measure specific to this registry rather than to GitHub.

The newest release is a database snapshot from January

The release history does not look like a normal CLI release stream, and the reason is visible in the tag names.

Three releases are listed. Two are package versions of skills-installer: 0.1.7 on 18 January 2026 and 0.2.0 on 20 January 2026. The third, published between them on 19 January 2026, is tagged v1.0.0-data and named Database snapshot 2026-01-19.

So a data snapshot is published through the releases mechanism as though it were a version. That is a reasonable way to version a crawl result, and it also means the tag namespace carries two different kinds of artefact: a package you install and a dataset you do not.

What is missing from the list is as informative as what is in it. No claude-plugins package version appears, even though that is the primary CLI and the one the quick start calls first. And the newest release of any kind is 255 days before the present date, while the last push to the default branch main is dated 28 September 2026.

So commits have continued for eight months past the last release. Anyone pinning skills-installer from npm is installing a build from January, and the newer work is only reachable from source.

MIT in the readme, no LICENSE file in the tree

A small inconsistency that matters for a tool that asks you to trust it with repository access.

The licence section at the bottom of the file says MIT, and there is a badge linking to the MIT licence text. The repository's licence field is empty, and there is no LICENSE file in the tree. The top level holds the GitHub configuration, a gitignore, agent instructions, the readme, a lockfile, an index module, the manifest, the packages directory, a patches directory, a skills directory and a TypeScript configuration.

For the CLIs this matters concretely. They are published to npm, and npm is where the licence a consumer reads comes from. A package published without a LICENSE file in its tarball reports no licence in `npm view`, so the MIT claim in the repository readme does not reach the place a user checks.

The published file list is worth knowing for the same reason. The root manifest ships nothing to the registry, since it is private, so the package contents come from the workspace packages under packages/.

Two other structural details are visible in the manifest. There is a single patched dependency, giget at 2.0.0, patched from a file in the patches directory, which means a fork of a transitive dependency that has to be carried forward. And TypeScript is a peer dependency rather than a direct one, with the only declared development dependency being the Bun type definitions.

Editorial conclusion

claude-plugins fits someone who wants a single searchable index across many agents rather than a folder of copied prompts, since the same identifier form resolves for both plugins and skills and the skill installer targets fifteen named clients. It is a poor fit if you want a self-contained catalogue, because the registry is a hosted function and index growth is capped by GitHub's API quota, which is why the project asks for your token. Before you install anything, check three things: whether your client supports skills at all, which the agentskills compatibility note asks you to verify, what Claude Code version you are on, since plugin support needs v2.0.12 or later, and whether you are comfortable granting the OAuth app read-only access to public data so it can join the token pool.

Frequently asked questions

Official sources

1. Issues
2. Kamalnrf/claude-plugins on GitHub
3. Project website
4. README
5. Releases