Ship it to your team through a marketplace

The plugin runs on your machine from a --plugin-dir flag. To get it onto your team’s machines you need one more layer: a marketplace — a catalog that lists one or more plugins and tells Claude Code where to fetch each one. Your teammates add the marketplace once, and from then on they install and update plugins from it by name. For a team, the marketplace is the difference between “here’s a folder, good luck wiring it in” and “run one command, you’re set up.”

The catalog file

A marketplace is itself just a file in a git repo: .claude-plugin/marketplace.json at the repo root. It names the marketplace and lists the plugins it offers, each with a source saying where the plugin directory lives:

{
  "name": "payments-team",
  "owner": {
    "name": "Payments Platform"
  },
  "plugins": [
    {
      "name": "payments-kit",
      "source": "./plugins/payments-kit",
      "description": "Database + Jira reach, the ledger gate, and the PR ritual"
    }
  ]
}

Here source is a relative path because the plugin lives in the same repo as the catalog — the common case for a team that keeps its tooling in one place. A source can also point at a separate GitHub repo when a plugin is maintained elsewhere. The full schema is on the marketplace docs page.

Hosting is nothing exotic: push the repo to GitHub (or any git host) and the marketplace is live. There’s no registry to register with, no build step. The catalog is the repo.

The hand-off

Now the payoff — what a new engineer actually does. They add your marketplace once and install the kit:

/plugin marketplace add payments-team/payments-tooling
/plugin install payments-kit@payments-team

The first command points Claude Code at your repo (here by its owner/repo shorthand). The second installs the plugin from it, namespaced by the marketplace so it’s unambiguous. And with that single install, everything you built across this whole course lands on their machine at once: the database and Jira MCP servers, the ledger-needs-test gate, the PR-ritual skill — all wired, all versioned. They didn’t copy a single file or read your settings.json. They ran two commands.

When you improve the kit — tighten the gate, add a server — you bump the plugin’s version and push. Your team picks it up with /plugin marketplace update and a reinstall. The setup stays in sync across everyone without anyone hand-merging config. A team that shares a marketplace converges on one agent configuration the way it converges on one set of lint rules: by reference, not by copy.

That’s the chapter. You took an agent that could only act on what it could already reach and gave it three things: reach into external systems via MCP, a deterministic gate via hooks, and a way to ship the whole setup as one installable plugin. Reach, gate, ship — the three ways you extend Claude Code past its defaults.

Where this goes next

Look back at the ledger hook — the gate that fires regardless of what the model decides, with nobody in the loop. At a terminal, with you watching every step, that property is a nice safety net. But it was built for a situation you haven’t hit yet: running Claude Code with nobody watching at all.

Everything in this course so far assumed you’re sitting there — approving an edit, reading a plan, reacting to a blocked commit. The next chapter drops that assumption entirely. Automation is Claude Code running headless: in a CI pipeline, wired into GitHub, kicked off by an event instead of a person. And when there’s no human in the loop, the deterministic gates and scoped permissions you just learned stop being convenience features and become the only thing standing between the agent and a production mistake. The kit you just built is exactly what makes running unattended safe.

Continue to Automation.