Claude Code plugins: install a workflow instead of copy-pasting it

Someone on your team finally got Claude Code behaving: a hook that blocks sloppy commits, a review command that catches real problems, a skill that writes migrations the house way. You know this because they pasted the whole setup into Slack, and you copied it into your repo. So did two other people.

Three weeks later the author fixed a bug in the hook. Your copy still has it. So does everyone else's, each drifted in its own direction, and nobody can say which repo runs which version of the team's best ideas.

Agent setup is spreading through your team the way code spread before package managers: by paste. Claude Code plugins exist to give your setup what your dependencies already have: an install command, a version, and a way to ship a fix.

What a Claude Code plugin actually is

A plugin is a folder with a manifest, and inside it the building blocks you already know, packaged to travel: slash commands, skills, hooks, subagents, and MCP server configs. One plugin can carry any mix of them: a single sharp command, or your team's entire way of working.

Plugins are distributed through marketplaces, and a marketplace is nothing exotic: a git repo with a catalog file listing what it offers. Run /plugin marketplace add anthropics/claude-code to add the official one, then /plugin to browse, install, enable or disable, exactly the loop of a package manager. The official docs cover the manifest details.

The key property: a plugin is one unit. Installed together, updated together, switched off together. The Slack paste gave you files; the plugin gives you a dependency, and dependencies can announce a new version.

Where a rule lives was settled; plugins decide how it travels

Sorting rules into homes is a solved question: universal context in your instructions file, occasional expertise in skills, triggered procedures in commands, unbreakable rules in hooks. Plugins answer a different question, and it is worth keeping the two apart. Not "where does this rule live?" but "how does this rule reach the next repo?"

• One repo needs it: commit .claude/ files in that repo. Done.
• Only you want it: keep it in your home directory config.
• Several repos or several people need it: that is the plugin case, and it is the only one of the three where paste was ever the tool.

The test is the third copy. The first paste is quick, the second is fine, and the third means you are now the maintainer of an unversioned fork you have already stopped thinking about.

When a Claude Code plugin pays off

• The same hook guards three repos. Every client project gets your test-before-commit hook and review command. A fix lands once, and /plugin updates make it everyone's fix.
• Onboarding stops being an afternoon of pastes. A new teammate runs one marketplace add and one install, and their first session behaves like yours: same commands, same guardrails, same skills.
• You want to borrow a whole workflow. Marketplaces are galleries of how other teams work. Installing a stranger's setup, trying it for a week, and uninstalling it cleanly is something paste never offered.
• You run agents on more than one machine. The plugin is the single source of truth; every checkout pulls the same behavior.

Where Claude Code plugins go wrong

The honest section, because packaging has real costs:

• A plugin is code you are choosing to run. Hooks execute shell commands, MCP servers reach the network, and instructions steer your agent. Read a third-party plugin the way you would read a stranger's pull request before merging it, because installing it is exactly that.
• Plugin soup has a debugging tax. Install four plugins and a rule fires that you never wrote. Now "why did the agent do that?" starts with an archaeology session through overlapping commands and hooks. Fewer, better plugins beat a long list you cannot audit.
• Packaging too early buys you release overhead. While a setup is still changing weekly, a plugin turns every tweak into a version bump. Let the config stabilize in one repo first; extract it when it stops moving, not when it is born.
• Rot scales with distribution. A stale command in one repo misleads one project. A stale plugin misleads every repo that installed it, with full confidence. Whoever publishes the plugin owns keeping it true.

Plugins standardize the sessions; SanuDesk runs them

A good plugin means every session you open starts expert: right commands, right guardrails, right skills. What it cannot do is open the sessions, decide what they work on, or check what came back. That operator layer is what SanuDesk is built for.

It is a desktop app that tiles your Claude Code, Codex and Gemini sessions into one grid, next to a Kanban board that does the dispatching: write the task as a card, deploy it to a fresh session with one click, and when the agent stops, the card parks itself in a review lane with a note on what changed and how to test it. Recurring chores become Loops that fire on a schedule, and a plugin is what makes those runs uniform: every session the Loop opens loads the same procedure, so Friday's run matches last week's. It is bring-your-own-model, driving the agent subscriptions you already pay for, and the grid and board are in the free plan (details on pricing).

Plugins make sessions interchangeable. The board is what keeps a fleet of interchangeable sessions pointed at the right work.

Package the setup you pasted last

Find the most recent agent config you copied between repos: that hook, that review command, that one skill. Put it in a fresh git repo as a plugin with a manifest, add a catalog file, and run /plugin marketplace add with your repo. Install it in two projects. The next time you improve it, notice that you edited it exactly once, and that the second repo got the fix by asking for it instead of by you remembering.

That is the whole promise: your agent setup starts compounding like software instead of drifting like folklore.

Download SanuDesk free to give your newly standardized sessions a grid and a board, or see how the grid, board and Loops fit together on the features page.