1. Claude Plugin Fundamentals
Note: The video covers material not in the guide below — please watch in full.
Action Step
Complete this before moving on.
Open the plugin menu on whichever surface you use — type /plugin in Claude Code (or open the plugins view in VS Code and in the browser) and look at the marketplaces and plugins already installed for your org. Notice what's there before you start building your own in the next training.
Training Guide
You already know what a skill is — a folder with instructions Claude reads inside a conversation. A plugin is how you go one level above that: a way to bundle multiple skills together, plus the tools, MCP servers, hooks, and connectors that make the whole thing just work the moment someone installs it.
Let's start with what a plugin actually is.
A Plugin Is a Folder With a Manifest
In one sentence: a plugin is a folder that has a plugin.json file at its root. That manifest is what registers the folder to Claude so it knows the whole thing is, in fact, a plugin.
If you went through the marketplace training, this should sound familiar. A marketplace was a folder with a marketplace.json. A plugin is a folder with a plugin.json. A skill is a folder with a skill.md. All the way up and down the ecosystem — marketplaces, plugins, skills — it's the exact same nomenclature: a folder with a manifest file that lets Claude read it.
The hierarchy nests. A marketplace holds plugins, and you can have multiple plugins in one marketplace. A plugin holds skills, and each skill has its skill.md plus other folders — reference, template, script, prompt. But the thing that makes a plugin special is that it can also ship commands, hooks, sub-agents, and connectors.
One important caveat: a skill inside a plugin runs identical to a loose skill. The wrapper changes nothing at runtime. The plugin just lets you carry the extra stuff alongside it.
So if a skill already works on its own, when do you actually need a plugin?
Plugins vs. Skills
A skill lives on the global or project level, and Claude reads it inside your session — inside the conversation where you're typing prompts.
A plugin extends Claude itself. Think about it this way: you have your session, and inside that session you call in a skill. A plugin operates on the layer around the session — what's called the harness level. It ships hooks, MCPs, and agents that control the thing surrounding the prompt window, not just what happens at the prompt line.
The way to think about it: a plugin is a box, and the skills go in that box — plus all the other stuff a skill can't carry.
The clearest example of "stuff a skill can't carry" is a hook.
Hooks: Code That Fires Behind the Scenes
A hook is deterministic code — a script that fires on an event, right before or after a message is sent. It runs behind the scenes. The user doesn't trigger it and usually doesn't even know it's there.
The use cases are basically unlimited: check the connectors when a session starts, or validate something before a tool runs, or confirm certain connectors are connected before a specific command is allowed to fire. This is the number one reason to use a plugin, because it's something a skill literally cannot do. And once you've built a hook, you can package it inside a plugin and disseminate it across your entire team.
Hooks aren't the only thing a plugin wires up behind the scenes — connectors are too.
Connectors: Ship the Wiring, Never the Keys
A connector is an MCP server shipped inside a plugin. Normally, when you add a connector manually in the Claude desktop app, it shows up in your connectors tab on the account level. But when a connector is packaged inside a plugin, it lives only inside the plugin — it doesn't show up in your settings. It's prompted based on when the user actually uses that plugin.
What the plugin ships is the wiring: "this plugin needs Salesforce and Gmail." When you install it, Claude knows it has to set those connectors up. The user still has to OAuth into each connector themselves.
This is critical from a security standpoint: plugins ship the wiring, never the keys. Never include tokens, secrets, or credentials inside a plugin. You're only shipping the requirement of the connector — the individual user authenticates into it on their own.
The last thing a plugin can ship is an agent.
Sub-Agents
In the plugin world, "agents" really means sub-agent prompts. Each sub-agent gets its own prompt — a .md file saved as an agent inside the plugin — so the main agent can hand work off to it without prompting from scratch.
Picture a CRM hygiene plugin with skills for dedupe, sales qualification, and validation. You might also ship a dedupe sub-agent: a pre-written specialist Claude with its own persona, like a code reviewer in the engineering department. Shipping it inside the plugin tells Claude, "this is a sub-agent available to me for this workflow."
Where Plugins Run, and When to Use One
Plugins run on every surface of Claude — there are org-level plugins you can download. You manage them with /plugin in Claude Code and VS Code (turn them on or off, see what's discovered, installed, and any errors), and in the browser, where you'll see both organization plugins and personal plugins.
So when do you reach for a plugin instead of a skill? Use a skill for a personal one-off where no special tools are needed. Use a plugin when a skill needs an MCP server wired up with it, when you have a family of skills that should ship and update together, when you need a hook, or when you're sharing with the team via a marketplace.
Wrap-Up
A plugin is the box that lets a skill travel with everything it can't carry alone — hooks, connectors, and sub-agents that operate around the session, not just inside it. It's a Claude-specific paradigm for now, and it runs everywhere Claude does. In the next training, you'll build one from scratch.
Comment in Slack
Post your answer in your onboarding channel.
What was your biggest takeaway(s) from this training?