How to Use Claude Code Plugins - Install a Whole Workflow in One Command

What is a Claude Code plugin?

A Claude Code plugin is a bundle that installs several working parts in a single command. Instead of adding a skill here, wiring a connector there, and setting up an automation separately, a plugin packages all of them together and installs them as one unit. A single plugin can carry skills, subagents, hooks, and connections to outside systems, and one install command sets up the whole set at once.

The reason this matters for a business is speed of setup and consistency across a team. Building a useful Claude Code setup by hand takes time and every person ends up with a slightly different version. A plugin turns that setup into a shareable package. One person builds or finds it, everyone installs the same command, and the whole team is running the identical workflow rather than seven personal variations of it.

• Skills are the procedures inside it - the written jobs Claude applies when a request matches.
• Subagents are helpers the plugin can spin up to handle a slice of a bigger task on their own.
• Hooks are triggers that fire automatically at set moments, such as before or after a job runs.
• Connectors are the live access to outside systems, so the plugin can reach your files or tools when a job needs real data.

How do I install a Claude Code plugin?

You install plugins with the /plugin command inside Claude Code. Type /plugin, browse the marketplace that loads by default, pick one, and install it. That default marketplace is the official one and it is the safest place to start, because everything in it has cleared a review bar rather than being pulled from an unknown source.

1. Open Claude Code and type /plugin. This is the hub for browsing, installing, and removing everything.
2. Browse the discover view. The official marketplace is loaded for you, so you can look before you install anything.
3. Pick a plugin and install it. The one command sets up every part the plugin carries at once.
4. Run a real job the plugin is meant to handle, and check the result the same way you would check any new tool.
5. Remove it through /plugin if it did not earn its place. Uninstalling is as clean as installing.

To use a plugin that is hosted somewhere other than the official marketplace, you add that marketplace first and then install from it by name. The pattern is: add the marketplace by pointing at where it lives, then run the install command for the plugin you want. This is also the point where care matters most, because a marketplace you add yourself has not been vetted for you.

How is a plugin different from a skill?

A skill is one procedure; a plugin is a packaged set of parts. A skill does a single repeated job, such as drafting a proposal in your voice. A plugin bundles several such pieces together with the connectors and triggers they need, so it sets up a whole workflow rather than a single task. Every plugin can contain skills, but not every skill is a plugin.

The practical takeaway is to learn skills first and plugins second. If you have never written a skill, start there, because a plugin is mostly skills packaged with plumbing. [How to use Claude Skills for your business](/blog/how-to-use-claude-skills-for-your-business) covers the single-procedure building block, and once that clicks a plugin is simply several of those shipped together.

What is the One-Marketplace Rule?

The One-Marketplace Rule is our safety rule for plugins: use only the official marketplace unless you have a specific, named reason to add another, and never add a marketplace you cannot vouch for. A plugin can carry connectors and triggers that reach into your systems and run on their own, which is real access. That is powerful when the source is trusted and a genuine risk when it is not.

The reason the rule is narrow is that the danger is narrow. Installing from the official marketplace is low risk because those plugins are reviewed. The exposure appears the moment you add an outside marketplace, because you are now trusting whoever built it with the access the plugin requests. Adding one for a good reason is fine. Adding one because a forum post told you to is how a business ends up running code it never inspected.

1. Default to the official marketplace. It is reviewed, and most businesses need nothing else.
2. Add an outside marketplace only for a named, specific plugin you actually need, never to browse.
3. Read what the plugin asks for. If it wants live access to your systems, treat that with the same care as any new integration.
4. Prefer plugins from sources you can identify and trust, the same standard you would apply to installing any business software.
5. Remove anything you are not actively using. An installed plugin with connectors keeps its access whether you use it or not.

How do plugins, skills, and MCP connectors fit together?

Skills carry procedure, connectors carry access, and a plugin is the box that ships a matched set of both. Most serious business setups use all three, and a plugin is just the packaging that keeps them together so they install and update as one unit rather than as loose parts you maintain by hand.

The access half is where most of the care goes, because a connector inside a plugin can read from or write to your real systems. Before you install anything that connects to your CRM, your files, or your email, understand what it can touch. [How to connect Claude to your business tools with MCP](/blog/how-to-connect-claude-to-your-business-tools-with-mcp) covers where to draw the line on write permissions, and that guidance applies doubly to a connector that arrived bundled inside a plugin you did not build.

Subagents are the other part worth understanding, because a plugin can install them to handle slices of a job on their own. [How to use Claude Code subagents for your business](/blog/how-to-use-claude-code-subagents-for-your-business) covers what they are and when they help, which makes it clearer what you are actually turning on when a plugin sets several of them up at once.

Which plugins should a business install first?

Install a plugin only when it packages a workflow you already know you want, never because it looks impressive in a list. The best first plugin is a small one from the official marketplace that handles a job you were about to build by hand anyway. If you cannot name the job it does for you in a sentence, you are collecting plugins rather than using them.

• A workflow you already run manually every week is the best candidate, because the payback is immediate and obvious.
• A setup you want identical across a team, so everyone installs one command instead of seven personal versions.
• A well-reviewed plugin from the official marketplace, over a niche one from a source you cannot identify.
• A small plugin over a large one at the start, because a focused bundle is easier to judge and remove.

Notice what is not on that list: a plugin you install to see what it does. Curiosity is fine in a personal account, but in a business account a plugin can carry access and run on its own, so idle installing is how you accumulate risk you are not tracking. Install with a job in mind, or do not install.

What goes wrong with plugins in practice?

The failures are predictable and all avoidable. They are not about the technology, they are about installing without a reason, trusting a source you did not check, and never removing what you stopped using. The same three habits that keep a software stack clean keep a plugin setup clean.

• Installing from an unvetted marketplace to save time, then running code and access nobody reviewed.
• Treating a plugin like a bigger skill, and not realising it can connect to systems and fire triggers on its own.
• Collecting plugins nobody uses, each one holding connectors and access it no longer needs.
• Skipping the check step, so a bundled connector reaches a system with more permission than the job required.
• One person installing something team-wide without agreeing what it can touch, which is a governance gap, not a tooling one.

The cleanest way to avoid all of it is to treat a plugin exactly like a new piece of business software: know who made it, know what it can access, install it for a stated job, and remove it when the job is done. [How to keep business data safe when using AI](/blog/how-to-keep-business-data-safe-when-using-ai) covers the wider habits that make this second nature.

Install one plugin this week

Open Claude Code, type /plugin, browse the official marketplace, and install one small plugin that handles a job you already do by hand. Use it on real work for a week, check its output, and remove it if it did not earn its place. One useful plugin you trust beats a folder of installed bundles you never audited, and the habit of installing with a job in mind is the whole skill. Our [guides](/guides) and [tools](/tools) pages cover the wider setup around it.