ANDROID_LAB_v1.0
Terminal_status: online

AI Coding

Claude Code Plugins: What You Should Know

Claude Code plugins package commands, skills, and integrations into installable extensions. How they differ from skills, and when to use them.

Developer reviewing a Claude Code plugin manifest and packaged commands in a terminal agent session

A Claude Code plugin is a packaged extension that adds capabilities to the agent, bundled commands, skills, and integrations you can install rather than build from scratch. Where a single skill teaches one procedure, a plugin distributes a whole set of them, often maintained by someone else. Plugins are how Claude Code’s behavior gets shared across teams and projects.

This is one of the newest layers of the tool, so it moves fast. As of May 2026, plugins behave roughly as described, but the packaging format, distribution model, and available plugins shift between releases. Treat this as orientation and verify specifics against the official Claude Code docs before relying on any of it.

What is a Claude Code plugin?

A plugin is a distributable bundle. Instead of writing instructions and helper files yourself, you install a package that brings them along. The point is reuse across people and projects, not just across your own sessions.

A plugin typically packages some combination of:

The mental model: a skill is something you write for your workflow; a plugin is something someone publishes so many people can install the same workflow. If you have used editor extensions or package managers before, the shape is familiar. You are extending a tool with someone else’s packaged work instead of reinventing it.

How do plugins differ from skills?

This trips people up, because both extend the agent and both can contain instructions. The cleanest way to keep them straight is by scope and source.

A skill is a single, focused instruction bundle, usually one you authored for one kind of task. A plugin is a distribution unit that can contain several skills, plus commands and integrations, packaged so others can install it. Skills are the ingredient; plugins are the cookbook you hand to the team.

Put differently: if you want the agent to follow your commit convention, you write a skill. If you want everyone on your team to get that convention plus your deploy commands plus your linting integration in one install, you package those as a plugin. We covered the skills layer on its own in Claude Code Skills: What You Should Know, plugins are the next step up, where reuse crosses people and not just sessions.

When should you use a plugin?

Plugins make sense when distribution is the problem you are solving. The capability already exists or you have built it; now you need it in many hands consistently.

Strong cases:

The common thread is more than one consumer. If you are the only person who will ever use a workflow, a plain skill is usually enough, packaging it as a plugin is overhead with no payoff.

Lab Notes, a plugin is a dependency, treat it like one. Installing a third-party plugin gives someone else’s instructions and integrations a seat at your agent’s table. Read what it does before you install it, the same way you would vet an npm package or a Gradle dependency.

What are the risks of installing plugins?

The convenience of plugins is also their risk: you are running code and instructions you did not write. That deserves the same scrutiny you give any dependency, and arguably more, because a plugin can shape what an agent does to your repo.

Things to check before installing a third-party plugin:

This is the same dependency-hygiene discipline that has always mattered in software, it just applies to agent behavior now. The principle holds across every AI tool decision: name the boundary, then choose what crosses it. We walk through that framing for the broader tool landscape in Claude Code vs Cursor.

How do you get started with plugins?

Start by being a careful consumer before you become a publisher. Most developers should install and evaluate existing plugins before packaging their own.

A reasonable path looks like this. First, make sure the agent itself is set up cleanly, if you have not yet, see Install Claude Code. Then identify a real, repeated need rather than installing plugins speculatively. Install one, use it on a low-stakes task, and watch what it actually does. Keep only what earns its place.

When you eventually package your own plugin, the discipline is the same as writing any shared library: clear documentation, a tight scope, and honest notes about what it touches. Because this layer is so new, the canonical reference is the Anthropic documentation, which will reflect format and distribution changes faster than any third-party post can. Verify there before you build something others will depend on.

How should a team decide what to package as a plugin?

For a team, the plugin question is really a question about which conventions deserve to be enforced versus merely suggested. Packaging something as a plugin is a soft form of standardization, it puts a workflow one install away for everyone, so it pays to be deliberate about what earns that treatment.

A useful filter is to ask whether the workflow is load-bearing. Some conventions genuinely matter for the codebase to stay coherent: how migrations run, where auth lives, which generated directories must never be hand-edited. Those are worth packaging, because the cost of someone doing them differently is real. Other conventions are preferences that vary by person and do no harm when they differ. Packaging those into a plugin imposes uniformity nobody asked for and creates a maintenance burden with no payoff.

There is also an ownership question. A shared plugin needs a maintainer, the same way a shared library does. If a plugin’s commands or integrations break after a tool update and nobody owns fixing it, the whole team inherits a confidently-wrong agent. Decide who maintains a plugin before you publish it internally, and prune plugins that have lost their owner.

The healthiest pattern most teams land on is small and conservative: package the handful of load-bearing, genuinely shared workflows, keep personal preferences in individual skills or local config, and resist the urge to turn every habit into a distributable. A short list of well-maintained plugins beats a sprawl of half-maintained ones every time.

Sources

// related