Claude Code packages team setups into a single plugin

Anthropic, the maker of Claude, has released a lesson on packaging an entire Claude Code setup and rolling it out to a whole team. It's lesson 9 of the "Claude Code in Action" course on Claude Academy, and it covers how to bundle skills, subagents, hooks, and MCP servers together so a single install delivers the whole package to teammates.

To unpack that a bit: Claude Code lets you customize its behavior through skills, subagents, hooks, and MCP servers. A plugin is what you get when you wrap that entire combination into one file bundle. Anthropic already mirrors a community-built list of plugins nightly to a GitHub repository (anthropics/claude-plugins-community), but this lesson covers the flip side—how teams build and share their own plugins.

Why packaging matters now

The lesson starts from a problem many Claude Code teams run into: even when one person builds a useful configuration, sharing it with teammates used to mean copying files over one by one. Moving skill folders, subagent markdown files, hook configs, and MCP server settings separately makes it easy for versions to drift out of sync or for pieces to go missing. A plugin compresses all of that into a single install unit, so one install command carries the entire configuration over intact.

What goes into a plugin

Component	Format
Skills	One folder per skill
Subagents	One markdown file per subagent
Hooks	Defined in hooks/hooks.json, run on every tool call
MCP servers	Defined in mcp.json
Settings	Only the agent and statusline keys from settings.json apply

You can also layer in language server protocol (LSP) servers, background monitors, and themes. The manifest file lives at .claude-plugin/plugin.json, and only the name field is required—version, description, and author are optional. You don't even need a manifest at all; Claude Code will inspect the folder structure and identify the components on its own.

How to use it

Installing and packaging use different commands.

Method	Command	Scope
Individual install	/plugin install org-name@plugin-name	Installs immediately in the current session
Team rollout	/plugin marketplace add org-name/repo-name	All future installs route through this marketplace

To use a plugin someone else made, you just type a single slash command in your session. For team-wide distribution, you first register a private marketplace once, and after that every install goes through centralized search, version tracking, and updates.

When building your own, you can just carry over the .claude directory structure you're already using. Put the skills folder, agents folder, hooks.json, and mcp.json at the plugin root, attach a name via plugin.json, and that's it. That name becomes the namespace, so a format like company-name/skill-name avoids colliding with skills from other plugins. For example, if you've already built internal code review rules and a deployment checklist as skills and hooks, you can take that structure as-is, add a manifest, and hand a new teammate a one-line install command.

Hooks run quietly

The lesson also flags the risk that comes with this convenience. Plugins execute code with the user's own permissions, and hooks fire automatically on any tool call that matches their conditions. Even if you only meant to install a plugin for its skills, that plugin's pre_tool_use and stop hooks come along whether you read them or not. The lesson notes that a community plugin could include a stop hook that calls out to a network endpoint with no warning shown anywhere in the settings screen.

The level of vetting depends on how a plugin was installed. Plugins submitted through the in-app form go through Anthropic's automated review before landing in the community marketplace, while the official marketplace is separately curated by hand. But passing review isn't the same as being trustworthy, so it's still necessary to check exactly which hooks, agents, and MCP servers come bundled in. Since plugins run alongside existing configurations rather than overwriting them, hooks can stack up—meaning multiple hooks from different plugins can fire on the same tool call at once.

Editor's take

What this lesson covers isn't a new feature—it's a way to scale an existing one up to team size. Last month, Anthropic built a distribution path by mirroring community plugins to GitHub. This time, it filled that path with something to put on it: a procedure for packaging individual configurations. Read in sequence, Anthropic's strategy becomes clear. Build the distribution channel first, then grow the number of producers.

The shift from npm to script-based installs, and the move to mirror the community marketplace as a repository, both point in the same direction: moving Claude Code from a personal tool toward a team standard. In that shift, what working teams need to prioritize isn't the tooling itself but the habit of verification. The fact that installing a plugin just to try one skill also brings its hooks along for the ride isn't something to brush past. Teams handling sensitive data—internal codebases, for instance—should make it standard practice to open the manifest and hooks.json before installing, and check exactly which tools are calling out to where.

From experience putting coding-agent tools to work in practice, verification steps tend to get pushed further back every time convenience features expand. This plugin structure is no exception. The easier a one-line install gets, the more a team needs the habit of checking what's riding along behind that one line—that's what prevents incidents. In the coming weeks, expect to see more teams building and rolling out their own internal standard plugins. But there's also a real chance we'll see incidents where teams installed unvetted community plugins as-is and ran into trouble.