anthropics/claude-plugins-official: How the Official Claude Code Plugin Directory Works

The official Claude Code plugin directory is trending on GitHub, with roughly 38,000 stars and 4,300 forks. The repository, anthropics/claude-plugins-official, describes itself as an "official, Anthropic-managed directory of high quality Claude Code Plugins." It is Apache-2.0 licensed, and it is the place /plugin install name@claude-plugins-official resolves against. If you build, install or recommend Claude Code plugins, it is worth understanding how it is organized and what it does and does not promise.

For context on plugins and skills in general, see our top 25 Claude plugins, the Claude plugin developer portal post, and the complete guide to agent skills.

TL;DR: questions answered

How the repository is laid out

Three locations matter:

• /plugins holds internal plugins developed and maintained by Anthropic.
• /external_plugins holds third-party plugins from partners and the community.
• /plugins/example-plugin is a reference implementation to copy from.

Every plugin follows one layout. Only the manifest is required:

plugin-name/
  .claude-plugin/
    plugin.json      required metadata
  .mcp.json          optional MCP server configuration
  commands/          optional slash commands
  agents/            optional agent definitions
  skills/            optional skill definitions
  README.md          documentation

That structure shows what a plugin can be: a bundle of slash commands, subagents, skills and MCP server wiring behind one install. If you have used the Model Context Protocol, the .mcp.json file is how a plugin ships an MCP server alongside its prompts.

Installing a plugin

The README gives one command:

/plugin install {plugin-name}@claude-plugins-official

You can also run /plugin and open Discover to browse. The README does not list individual plugins beyond the example, so the catalog lives in the two folders and in the Discover menu. Our own plugin ranking covers popular picks, and the Claude Code commands reference explains the surrounding slash commands.

Two practical habits: read the plugin's README and homepage before installing, and prefer plugins in /plugins (maintained by Anthropic) over /external_plugins when both could do the job, since the second group is maintained by outsiders.

How to submit a plugin

Anthropic team members develop the internal plugins. Everyone else uses the plugin directory submission form linked from the README. The stated bar is that submissions "must meet quality and security standards for approval." The README does not publish the criteria, review time or an appeals path. If you plan to publish, our developer portal guide covers tracking usage after approval.

Rules that will bite you if you ignore them

Plugin names are immutable. The name field is a permanent slug. Renaming it breaks existing installs with a plugin-not-found error. To change what users see, edit displayName. If a rename is truly unavoidable, add an entry to the renames map in .claude-plugin/marketplace.json:

"renames": {
  "old-name": "new-name"
}

Skill bundles can skip plugin.json. A skill-bundle plugin can be published without a plugin.json by setting strict: false and listing an explicit skills array. The example in the README points a git-subdir source at a path inside a larger repository, pins a ref and a commit sha, and registers each skill as <plugin-name>:<skill-name>. This is useful if your skills already live inside an SDK repository and you do not want a separate plugin repo. Pinning the commit is also what makes the bundle reproducible.

The security warning, in plain terms

The README's warning is blunt: "Make sure you trust a plugin before installing, updating, or using it. Anthropic does not control what MCP servers, files, or other software are included in plugins and cannot verify that they will work as intended or that they won't change."

Read that as three separate risks:

1. Content risk. A plugin can include commands and skills that steer your agent, and MCP servers that run code on your machine.
2. Behavior risk. Anthropic does not promise a plugin does what its description says.
3. Change risk. A plugin can change after you approve it. An update can introduce new behavior, which is why the warning covers "updating" as well as installing.

Practical defenses: install from /plugins first; pin versions where the tooling allows; review .mcp.json for the commands it launches; and run agents with limited permissions. For runtime protection, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions. The same trust questions apply to community collections such as ECC and Superpowers, which publish their own marketplace entries as well; Superpowers' README, for example, lists both superpowers@claude-plugins-official and its own marketplace as install routes.

What the star count does and does not mean

With about 38,000 stars, the repository is popular, and 1,100 open issues show an active user base filing requests and problems. Stars tell you people bookmark it; they do not measure plugin quality. The more informative signals are in the directory itself: who maintains a plugin, when it last changed, whether it pins its dependencies, and whether its MCP servers are open source.

What people are asking

Is "official" the same as "safe"? No. "Official" here means the directory is managed by Anthropic and that submissions go through a review. The README itself says Anthropic cannot verify that plugins behave as intended or will not change. Treat the directory as a curated catalog with a front door, not as a guarantee. Plugins in /plugins are written by Anthropic staff; those in /external_plugins are written by others, even though both resolve under the same @claude-plugins-official suffix.

Why does the install command end in @claude-plugins-official? Claude Code supports multiple plugin marketplaces. The suffix names the marketplace the plugin comes from, which avoids collisions when two marketplaces carry a plugin with the same name. Other projects publish their own marketplaces, and you add them with a marketplace command before installing from them, as the community collections we cover do.

Can a plugin bundle skills only? Yes. The skill-bundle format with strict: false exists exactly for that: a list of skill folders, a source, and optional metadata such as category and homepage. If all you have is a set of skills in a repo, you do not need commands, agents or an MCP server to ship them.

What happens when I update a plugin? Updates can change commands, skills and MCP launch commands. Because the README's warning covers updating, re-read the changes for plugins that hold credentials or run servers. For plugins you depend on in a team, agree on a review step before upgrades, the same way you would for a package dependency.

How do I debug a plugin that will not load? Start with the manifest. The only stated requirement is .claude-plugin/plugin.json, so a missing or misplaced manifest is the first thing to rule out. The plugin-not-found error mentioned in the README is specific to renamed plugins, so if you see it after a rename, check the renames map.

How the directory fits the wider plugin ecosystem

Claude Code plugins sit between two other extension mechanisms. Skills are the lightest: markdown instructions that load when relevant, covered in our agent skills guide. MCP servers are the heaviest: running processes that expose tools. A plugin can package both, plus slash commands and subagents, so one install gives you a coherent capability rather than five separate setups.

That packaging is why the directory matters. A single trusted source of installable bundles lowers the cost of discovery, and it gives plugin authors one place to be found. The cost is concentration: a popular listing becomes a target for lookalikes and for supply-chain tampering. The README's emphasis on immutable names and pinned skill-bundle commits are design choices that reduce, but do not remove, that risk.

For teams, a sensible policy is to maintain an allowlist of approved plugins, record the exact marketplace and version in documentation, and review additions in the same pull request as the project change that needs them. For individuals, the habits that matter are reading before installing, preferring Anthropic-maintained entries, and removing plugins you no longer use, since each one keeps a standing ability to influence your agent.

A quick audit checklist before you install

1. Is the plugin under /plugins (Anthropic) or /external_plugins (third party)?
2. Does plugin.json declare what you expect, and does the README match the code?
3. Does .mcp.json launch anything that needs network access, secrets or filesystem writes?
4. Do commands or skills include shell instructions you would not run by hand?
5. Is there an active maintainer, recent commits and a license (remember: the repo is Apache-2.0, but each plugin may differ)?
6. Do you need it enough to accept the change risk of future updates?

Five minutes on this list beats cleaning up after a plugin that quietly widened your agent's reach.

Publishing your own: what to prepare

If you maintain a plugin and want it listed, prepare the pieces reviewers will look for. Write a manifest that says plainly what the plugin does and which tools it touches. Document every MCP server it starts and what data each can read. Pin versions and commit hashes so a listing refers to reviewed code. Choose a stable name before you submit, since it cannot change later without a migration entry. And write a README that tells users how to uninstall and how to report problems, because the directory's issue tracker is busy and a clear maintainer contact helps.

Related reading

• Top 25 Claude plugins
• Claude plugin developer portal: submit and track usage
• What are agent skills? A complete guide
• ECC: 71 agents and 311 skills
• Superpowers skills framework
• What is MCP?

Details are from the repository README on October 15, 2026. See the official plugin documentation for current behavior.