Kamalnrf/claude-plugins: a registry and two CLIs for Claude Code plugins and agent skills

The problem: plugin discovery is scattered across marketplaces and repos

Claude Code plugins and agent skills live in many separate GitHub repositories. Finding one means reading a README, copying a clone URL, and putting the files in the right directory by hand. Kamalnrf/claude-plugins collapses that into one index and one identifier format. The README describes the registry as automatically discovering and indexing all public Claude Code plugins and agent skills on GitHub, and states that the site currently lists 11,989 Claude Code plugins and 63,065 agent skills. Those counts are the project's own published figures, not an independent measurement, and they say nothing about the quality of any entry. The intended user is someone who already runs an agent that supports plugins or skills and wants installation to be a one-line command instead of a manual clone. The README also notes that the registry is approaching GitHub API rate limits at 5,000 requests per hour, which is why the project asks users to donate a read-only token to a shared pool. That detail matters: the index depends on a quota the maintainers do not control.

How the registry and the two CLIs resolve an identifier

Both tools follow the same three steps, as documented in the README. You run an install command with an identifier in the form @owner/repo/name. The registry returns the Git repository URL for that identifier. The CLI clones the repository and installs the plugin or skill. There is no build step described and no manifest format documented in the README beyond the identifier itself, so the practical contract is: if the repository is indexed and the path inside it matches, the clone succeeds. The two CLIs split by target. claude-plugins manages Claude Code plugins and writes them to ~/.claude/plugins/marketplaces/. skills-installer handles agent skills for agentskills-compatible clients and writes to ~/.claude/skills/ globally or ./.claude/skills/ when you pass --local. The registry itself is a Val Town function, the CLI is built with Bun, and the web app uses Astro, according to the tech stack section. One consequence of resolving everything through a hosted registry is that the identifier namespace is not something you control locally: an install is only as reproducible as the registry response at that moment.

Installing claude-plugins and running a first install

The README gives a global npm install for the plugin CLI. The same page warns that Claude Code v2.0.12 or later is required for plugin support, so check that before anything else.

npm install -g claude-plugins

After the install completes, the install subcommand takes a registry identifier. The README's quick start uses this exact one:

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

The CLI resolves that identifier through the registry, clones the repository, and places the plugin under ~/.claude/plugins/marketplaces/. You can confirm what landed with the list command, and toggle entries later with enable or disable:

claude-plugins list
claude-plugins disable compound-engineering
claude-plugins enable compound-engineering

If you prefer not to install globally, the README's quick start uses npx for the same command, which runs it without a persistent global package.

Installing skills-installer and targeting a client other than Claude Code

Skills are a separate CLI with a separate registry view. Install it globally first:

npm install -g skills-installer

The README's example installs a skill from the anthropics namespace. Note that the identifier shape is the same as for plugins:

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

The default target is claude-code. To install for another supported client, pass --client with one of the documented flags. The README lists fifteen, including cursor, windsurf, vscode, codex, amp, opencode, goose, letta, github, gemini, antigravity, trae, qoder and codebuddy:

skills-installer install @anthropics/claude-code/frontend-design --client cursor
skills-installer install @anthropics/claude-code/frontend-design --local

Without --local the skill goes to ~/.claude/skills/; with --local or -l it goes to ./.claude/skills/ in the current directory. The README points readers at agentskills.io to check whether a given client supports skills at all, which is the right first check: the flag list tells you what the CLI will write, not what your client will read.

Searching from the terminal instead of the website

The skills-installer search command is the part of this project that has no obvious equivalent in a plain git workflow. Running it with no argument opens an interactive terminal browser where you can search, sort by relevance, stars or installs, and install without leaving the shell. Running it with a query string narrows the results directly.

npx skills-installer search

The README documents sorting by stars as one of the options. That is worth a caveat: a star count is a popularity signal from GitHub, and the project's own README treats stars as a discovery aid rather than a quality measure. Use the sort to narrow a long list, then read the repository before installing. The search command covers skills, not Claude Code plugins; for plugins the README points to the website instead.

The skills-discovery meta skill and how much autonomy it actually grants

There is a second path that inverts the workflow: instead of you searching, the agent does. Installing the skills-discovery meta skill is documented as a normal skills-installer command.

npx skills-installer install @Kamalnrf/claude-plugins/skills-discovery

According to the README, once installed the agent will proactively search for relevant skills before starting tasks, help compare skills, and install skills with your confirmation. The confirmation step is the important part of that sentence. The README does not describe a permission model, an allowlist, or a review queue, so the practical safeguard is the confirmation prompt in your client, not anything in this project. If your client surfaces that prompt weakly, or if you run agents unattended, this meta skill is the wrong tool.

Where this breaks down: no vetting, a hosted registry, and a thin CLI surface

The registry indexes public GitHub repositories automatically. Nothing in the README describes a review step, a signing mechanism, or a malware scan before an entry appears. Installing a plugin therefore runs whatever that repository contains, with the same trust you would extend to cloning it yourself. That is not a flaw unique to this project, but it is the constraint to plan around: treat the registry as a discovery index, not a trust boundary. The second limitation is dependency on a hosted service. Identifiers resolve through a Val Town function, and the project states it is approaching GitHub's 5,000 requests per hour limit and is recruiting donated tokens to spread the load. If the registry is rate limited or unavailable, installs fail even though the plugin repository is fine. Third, the documented CLI surface is deliberately small. claude-plugins offers install, list, enable and disable; skills-installer offers search, install and list. The README does not document an uninstall command, a version pinning syntax, or a rollback path, so removing or reverting an installed plugin is a manual filesystem operation in ~/.claude/plugins/marketplaces/ or ~/.claude/skills/.

Compared with installing straight from a Git repository

The alternative most readers already have is git clone plus a copy into the client's directory. That approach has no registry dependency, no rate limit, and no identifier indirection: you know exactly which commit you fetched. What it lacks is discovery and cross-client placement. The registry gives you a searchable index of tens of thousands of entries and a single identifier format, and skills-installer writes into the directory layout each supported client expects, which is tedious to reproduce by hand across fifteen clients. The trade-off is control. A direct clone lets you pin a commit and inspect the tree before it is active; the registry path resolves a name to whatever the repository currently is. If you already know which plugin you want and you care about reproducibility, cloning is the better route. If you are exploring, or you install skills across several clients, the registry saves real time.

Editorial conclusion

Adopt it if you install plugins or skills by hand and want one identifier format that resolves to a Git URL, plus a search command that runs in the terminal. Skip it if you need a curated or security-reviewed catalog: the README describes automatic indexing of public GitHub repositories, so nothing is vetted before it appears. Before rolling it out, verify that your Claude Code build is v2.0.12 or later, that your client is in the supported list, and that you are comfortable with installs landing in ~/.claude/plugins/marketplaces/ and ~/.claude/skills/ (or ./.claude/skills/ with --local).

Frequently asked questions

Official sources

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