In part 1 you turned a convention into a skill and committed it to the repo. Everyone who clones that repo gets it. Problem solved — for one convention, in one repo.
But your real setup is more than one skill.
It’s the add-endpoint skill and a subagent that reviews diffs the way your team reviews them and a hook that runs dotnet build after every edit so nobody merges code that doesn’t compile and an MCP server pointed at your staging database. That’s four things, in four places, and your team has ten people and a dozen repos.
Copying all of that around by hand is how drift starts. One repo has the latest review subagent, another has last month’s. One developer set up the build hook, three didn’t. Within a sprint, “how we work” is different on every machine.
A plugin fixes that. It bundles the whole setup and installs it with one command.
What a plugin actually is
A plugin is a versioned bundle of Claude Code extensions. One directory can contain:
- skills — like the
add-endpointskill from part 1, - subagents — specialised agents with their own context, e.g. a code reviewer,
- commands — your own slash commands,
- hooks — scripts that fire on lifecycle events (before a tool runs, after an edit, when Claude finishes),
- MCP definitions — connections to your database, issue tracker, or internal APIs.
One /plugin install and a developer gets all of it at once. Update the plugin, bump the version, and everyone pulls the same change. No gists, no “copy my config”, no Slack thread titled “my Claude Code setup (final)(v2)”.
The blog already has a post on discovering plugins in the marketplace. This one is about the other direction: building and shipping your own.
The layout
A plugin is just a folder with a manifest. Here’s a minimal team plugin:
acme-dotnet/
├── .claude-plugin/
│ └── plugin.json
├── skills/
│ └── add-endpoint/
│ └── SKILL.md # the skill from part 1
├── agents/
│ └── dotnet-reviewer.md # a review subagent
└── hooks/
└── hooks.json # run dotnet build after edits
The manifest ties it together:
{
"name": "acme-dotnet",
"version": "1.0.0",
"description": "Acme's shared Claude Code setup for .NET services.",
"author": "Platform team"
}
That’s the whole idea: take the things you already have and put them under one roof with a version number.
The pieces
The skill you already wrote in part 1. Drop the folder in as-is.
The subagent is a markdown file with a bit of front matter — a reviewer that knows your .NET pitfalls:
---
name: dotnet-reviewer
description: Reviews a diff for our .NET conventions before a PR.
tools: Read, Grep, Bash
---
You review C# changes for this team. Flag, in order of severity:
- `async void` outside event handlers
- endpoints that throw instead of returning `Result<T>`
- `DbContext` used directly from a handler
- EF Core queries that will run N+1
- new public API without an xUnit test
Report only what you're confident about. No style nitpicks.
The hook is where a plugin earns its keep, because a hook runs deterministically — it doesn’t depend on anyone remembering. This one builds after every edit so a compile error surfaces in seconds, not in CI:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "dotnet build --nologo -clp:ErrorsOnly"
}
]
}
]
}
}
A skill suggests how to write code. A hook checks it, every time, on every machine that has the plugin. That difference is the whole reason to bundle them together.
Shipping it to the team
You distribute a plugin through a marketplace — which sounds grander than it is. A marketplace is just a git repo with a small index file, and it can be a private repo on your own GitHub org.
Add a .claude-plugin/marketplace.json that lists your plugin, then a teammate runs:
# once, to add your internal marketplace
/plugin marketplace add acme/claude-tooling
# then install the bundle
/plugin install acme-dotnet@acme-tooling
That’s it. They now have the skill, the reviewer, and the build hook — the same versions you do.
When the convention changes, you change it in one place. Bump the version, and everyone gets the update the next time they pull the plugin. Your team’s way of working now has a release process, the same as your code.
Where this gets sharp
Two things to take seriously, because a plugin is more powerful than a skill.
Hooks run code on your teammates’ machines. That dotnet build command is harmless, but the mechanism isn’t picky — a hook can run anything. When you ship a plugin, you’re asking people to trust it the way they trust a dependency. Keep the repo access-controlled, review hook changes like production code, and never pull a plugin into your team’s setup that you haven’t read.
A shared setup can spread a mistake as fast as a fix. The upside of “everyone gets the same thing instantly” has an obvious downside. A broken hook doesn’t inconvenience one person; it stops the whole team. So version deliberately, and treat a plugin release with the same care as a deploy — because for your team’s workflow, it is one.
Try it this week
Take the skill you wrote after part 1 and add exactly one more thing to it: a single hook that runs dotnet build (or your fastest test project) after edits. Put both in a plugin folder with a plugin.json, push it to a repo, and have one colleague install it.
You’re not rolling it out to everyone yet — you’re proving the loop: build once, install anywhere, update in one place.
How do you distribute your Claude Code setup today — a plugin, a shared repo, or still copying files by hand? Tell me in the comments. I suspect most teams are further behind on this than they’d like to admit, and I’d genuinely like to see how people are solving it.
This is part 2 of a short series on running Claude Code across a whole team. Part 1 was the shared skill.
Next — Part 3, on 3 August: the uncomfortable question. When your whole team is shipping AI-written code this fast, who’s actually accountable for it — and how do you build the review gates that keep a human in the loop?
Comments