Heads up: There is currently a bug in Claude Code where installing a plugin at the local or user scope prevents you from reinstalling it into a different project (anthropics/claude-code#14202). If you hit this, plugin-rescope is a quick workaround:

npx plugin-rescope my-plugin@marketplace

It rescopes the plugin registration to your current project so you can use the same plugin across multiple codebases without conflicts.

DRY Is Not Just About Code

Every developer knows the DRY principle: Don't Repeat Yourself. We refactor duplicated functions, extract shared utilities, and build abstractions to avoid writing the same logic twice. But we almost never apply that thinking to our development environments.

Think about how you set up a new project with Claude Code. You write a CLAUDE.md with your conventions. You define custom slash commands in .claude/commands/. You configure agents in .claude/agents/. You set up hooks in your settings. Then you start a new project and do the exact same thing. Copy-paste the agent definitions, rewrite the commands, reconfigure the hooks.

That is a DRY violation. It just happens outside your source code, so it feels invisible.

The cost compounds. You fix a bug in your PR review agent in one project and forget to port it to the other three. You refine a deployment skill and it only exists in one repo. Your tooling diverges across projects, and the "best version" of each workflow is scattered across different codebases with no single source of truth.

The Distribution Problem

The real issue is distribution. When your AI tooling lives inside .claude/ in a single project, it is coupled to that project. There is no mechanism to version it, share it, or update it across repositories.

This is the same problem package managers solved for code decades ago. You don't copy-paste lodash into every project. You install it, pin a version, and update when you are ready. Your development environment tooling deserves the same treatment.

Plugins as the Fix

Claude Code plugins are the package manager for your AI workflows. A plugin is a directory that bundles any combination of skills, agents, hooks, and MCP servers into a single installable unit.

The structure is straightforward:

my-plugin/
├── .claude-plugin/
│   └── plugin.json        # name, description, version
├── skills/                 # slash commands
├── agents/                 # specialized agents
├── hooks/                  # event handlers
└── .mcp.json               # external tool integrations

You install plugins through the /plugin command or via marketplaces. Skills get namespaced automatically (/my-plugin:review instead of /review), so multiple plugins can coexist without stepping on each other.

Quick Start

Create a plugin manifest:

{
  "name": "my-workflow",
  "description": "Shared dev workflows",
  "version": "1.0.0"
}

Add a skill at skills/review/SKILL.md:

---
name: review
description: Review code for team standards
disable-model-invocation: true
---

Review the changed files for:
1. Naming conventions
2. Error handling patterns
3. Test coverage

Test it locally:

claude --plugin-dir ./my-workflow

When it works, push it to a Git repository and distribute it through a marketplace. Others install it with /plugin install and get your exact workflow, versioned and updatable.

Marketplaces

Anyone can host a marketplace by creating a Git repository with a .claude-plugin/marketplace.json file. Point your team to it and they can browse and install plugins through the /plugin command. Anthropic also maintains an official marketplace with community-contributed plugins.

The Road Ahead

Plugins are in public beta, and it shows in places. Beyond the scoping bug mentioned at the top, there are a few things to keep in mind:

Plugin discovery is still young. There is no centralized registry like npm. Marketplaces are Git repositories you have to know about and add manually. Finding the right plugin for your use case requires word of mouth or browsing GitHub.

No dependency management. Plugins cannot declare dependencies on other plugins. If your plugin needs an MCP server that another plugin provides, the user has to install both manually and hope they are compatible.

Version pinning is manual. When you install a plugin, you get whatever is on the default branch. There is no lock file, no automatic update notifications, and no way to pin to a specific release without forking.

Testing story is thin. You can test plugins locally with --plugin-dir, but there is no test framework for plugin authors. If your skill spawns agents or interacts with hooks, verifying correctness is on you.

Namespace lock-in. Your plugin name becomes the namespace prefix for every skill. Renaming a published plugin breaks every user's muscle memory and any scripts that invoke skills by name.

None of these are dealbreakers. The core idea is sound: package your AI workflows, version them, distribute them. The infrastructure around it will mature. If you have been copy-pasting .claude/ directories between projects, plugins are already a net improvement even with these rough edges.

Start small. Take the one workflow you keep recreating and turn it into a plugin. When the ecosystem catches up, you will already have your tooling portable.