Video: Plugins
1. Video: Plugins
A setup you trust is worth more when your whole team runs it. Plugins are how Claude Code packages a setup and moves it between people. And there are two sides to that, using the plugins other people publish and packaging your own once you've built something worth sharing. A plugin is one installable unit. Where it lives sets how you install it. Inside a session, /plugin install the organization name at the plugin name does the same thing. For a team, add a private marketplace once with the /plugin marketplace add your organization slash Claude plugins or whatever you want to call it. And every install after that results through it with centralized discovery, version tracking, and updates. Now a plugin runs code on your machine with your privileges and its hooks fire on every matching tool call. Install it for the skills and you also get its PreToolUse and stop hooks whether you read them or not. A community plugin can ship a stop hook that calls out to a network endpoint and nothing in your configuration will warn you. See every hook, agent, and MCP server that it adds. Install plugins and add marketplaces only from sources that you truly trust. The in-app submission form posts to the community marketplace after Anthropic's automated review. And the official marketplace is curated on its own track. Reviewed isn't the same as trusted though, so check what it does. A plugin doesn't overwrite your configuration. Its components run alongside yours. So first, hooks stack together. A plugin's PreToolUse and your own both fire on every tool call, which is the reason you read the details first. Skills, agents, and commands are namespaced under the plugin name so they never clash. A plugin can also ship a settings.json file but a narrow one. So Claude Code honors only the agent and subagent status line keys. Setting agent promotes one of the plugins subagents to the main thread with a system prompt, tool, restrictions, and model. And enabling that plugin changes how Claude Code behaves by default, which is one of the main reasons to look before you even turn it on. So once you've built a .claude directory, instead of your team copying and pasting between machines, package it instead. A plugin bundles all of it as one version installable unit. Skills, subagents, hooks, and MCP server configs, plus the longer tail of the language server protocol servers, background monitors, themes, and a settings.json slice. The manifest lives at .claude-plugin/plugin.json and holds the name, version, description, and author. It's optional but leave it out and Claude Code discovers components by directory convention. The directory structure does the rest. The same .claude shape that you already use with skills with one folder per skill, agents with one markdown file per subagent, hooks slash hooksjson and .mcpjson all at the plugin root. Name is the only required field and it namespaces your skills as the company name, skill name. Version it like any other dependency. When you use plugins, read before you install. When you build one, package your .claude the moment it works. One manifest, one install, and the setup you trust reaches your entire team.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.