Claude Code Plugin Marketplace

A Claude Code plugin marketplace is a git repository or hosted JSON file containing a .claude-plugin/marketplace.json catalog that lists installable plugins. You add the marketplace once, then install plugins from it by name. To add one from GitHub and install a plugin:

/plugin marketplace add owner/repo
/plugin install plugin-name@marketplace-name

For example, Anthropic’s official marketplace registers itself the first time you start Claude Code interactively, so most people install straight from it without adding anything first. Run /plugin to browse what it already offers and install from there rather than typing an identifier you are guessing at.

List, update, and remove work the same way:

/plugin list                              # installed plugins; add --enabled or --disabled
/plugin marketplace list                  # marketplaces you've added
/plugin marketplace update marketplace-name
/plugin disable plugin-name@marketplace-name
/plugin uninstall plugin-name@marketplace-name
/plugin marketplace remove marketplace-name

/plugin on its own opens an interactive panel with Discover, Installed, Marketplaces, and Errors tabs, per Anthropic’s plugin marketplace docs. Removing a marketplace uninstalls every plugin you got from it, so don’t do that to free disk space, there isn’t any to free.

If you’re building your own plugin rather than installing one, skip to publishing a plugin below.

What a plugin can actually contain

A plugin is a directory. Its manifest, .claude-plugin/plugin.json, is optional if the plugin only uses default component locations, but the components live at the plugin root, never inside .claude-plugin/:

A plugin that ships one skill can put SKILL.md at the root instead of nesting it under skills/. Everything else, bin/ executables, monitors/monitors.json background watchers, is secondary to the four that matter for most installs: commands, agents, hooks, skills.

The context cost of a plugin

This is the part the directory listicles skip. A plugin is not free just because it’s installed. Every command, agent definition, and hook that Claude Code loads at session start becomes part of what gets re-sent on every turn of every session in scope, whether you invoke it that turn or not. Ten plugins each adding a handful of always-loaded instructions is a standing tax you pay before you type a single message.

Skills are the exception by design: they’re model-invoked, meaning their frontmatter description is what’s loaded up front (cheap), and the full body only enters context when Claude decides to use one. A commands directory or an agent definition file behaves the same way component-for-component, but an MCP server’s tool schemas are the worst offender if the server isn’t using deferred tool listing, since those get enumerated in full on every request.

Two ways to check what you’re actually paying:

• Run /plugin, open a plugin’s detail view, and read its Context cost estimate before installing. Not every marketplace supplies this, local and custom marketplaces often show Components will be discovered at installation instead.
• Run /context in a live session to see what’s currently consuming your context window, broken down by source. If a plugin you installed months ago and forgot about shows up as a chunk of standing overhead, that’s your answer.

The Installed tab also flags plugins you haven’t used in two weeks across ten or more sessions under a Not used recently header, precisely because an unused plugin still costs tokens every turn. Rule of thumb: an always-loaded instruction file (a command, an eagerly-loaded agent prompt) is a tax you pay whether or not you use it; a properly authored skill is not, because its body stays out of context until Claude reaches for it.

Managing what’s installed

/plugin enable plugin-name@marketplace-name
/plugin disable plugin-name@marketplace-name
/reload-plugins

Installing or enabling a plugin doesn’t always take effect immediately. The install summary tells you: Plugin is now active. means it’s live, Run /reload-plugins to activate. means you need that command, because activating would otherwise invalidate the prompt cache. /reload-plugins --force overrides the cache-invalidation warning when you want to push through it anyway.

For non-interactive installs (CI, containers, scripting), the shell-level command skips the panel:

claude plugin install plugin-name@marketplace-name --scope project
claude plugin uninstall plugin-name@marketplace-name --scope project

--scope is user (default), project (written to .claude/settings.json, shared with collaborators), or local (yours only, this repo).

Publishing your own plugin

This is the half of the query the directory pages don’t cover, and it’s genuinely two files plus a folder structure.

The plugin itself

my-plugin/
├── .claude-plugin/
│   └── plugin.json
├── commands/
├── agents/
├── skills/
└── hooks/
    └── hooks.json

plugin.json defines identity:

{
  "name": "my-plugin",
  "description": "What this plugin does, shown in the plugin manager",
  "version": "1.0.0",
  "author": {
    "name": "Your Name"
  }
}

name becomes the namespace prefix for every command and skill the plugin ships (/my-plugin:whatever). version is optional; if you set it, users only get updates when you bump it (per Anthropic’s plugin creation guide). Test locally before publishing anything:

claude --plugin-dir ./my-plugin

The marketplace manifest

A marketplace is a separate repo (or the same repo, your call) with .claude-plugin/marketplace.json at its root:

{
  "name": "my-marketplace",
  "owner": {
    "name": "Your Name"
  },
  "plugins": [
    {
      "name": "my-plugin",
      "source": "./plugins/my-plugin",
      "description": "What this plugin does",
      "version": "1.0.0"
    }
  ]
}

name and owner are required at the top level; each entry in plugins needs at minimum name and source. source can be a relative path into the same repo, or an object pointing elsewhere: {"source": "github", "repo": "owner/repo"}, a git URL, a git subdirectory, an npm package, or an archive URL. Validate before you ship it:

claude plugin validate .

Someone installs from your repo exactly the way they’d install from any other marketplace:

/plugin marketplace add owner/your-marketplace-repo
/plugin install my-plugin@my-marketplace

Pin them to a branch or tag with owner/repo@v1.0, or point at a local path (/plugin marketplace add ./path/to/marketplace) while you’re iterating with a team before it’s public.

Discovery

Anthropic runs its own marketplaces, a curated one that auto-registers and a community one for third-party submissions. Their install identifiers are worth reading off /plugin rather than off a blog post: the marketplace docs reserve several similar names (claude-plugins-official, claude-plugins-community and claude-community among them) without stating which reserved name each live marketplace answers to. Beyond those, most plugin discovery today happens by word of mouth, README links, and the official catalog at claude.com/plugins rather than a single canonical index. If you’re publishing one, the README install snippet is what actually gets copy-pasted, so get the exact commands right and keep them there.

shiploop as a plugin

shiploop ships as a Claude Code plugin, installed the same way as anything above, straight from the shiploop repo:

/plugin marketplace add anshss/shiploop
/plugin install shiploop@shiploop

Once installed it adds five slash commands: /shiploop:setup (scaffold or upgrade a workspace), /shiploop:flows (inventory and validate user-facing paths), /shiploop:update (pull the latest hub templates down), /shiploop:push (port local fixes back upstream as a reviewed PR), and /shiploop:statusline (show the running fleet in your statusline). None of it does anything until you run /shiploop:setup on a project.

For more on what’s worth installing versus what quietly taxes every session, see the full guide list.

Last updated 2026-09-04.