Claude Code Plugins for Client Work

What a Claude Code Plugin Actually Is

A Claude Code plugin is a single installable package that bundles the pieces you would otherwise configure by hand on every project: slash commands, subagents, hooks, and MCP server connections. You install it once in a project and everything inside it becomes available immediately. It is the difference between carrying a toolbox and rebuilding each tool at every job site.

Each part solves a different problem. Slash commands are reusable prompts you trigger by name. Subagents are specialised assistants you delegate a narrow task to, like reviewing code or drafting a client update. Hooks run automatically at defined points, such as formatting a file every time it is saved. MCP servers connect Claude Code to outside tools like a database, a calendar, or a project tracker. A plugin lets you ship all of them as one unit.

For a solo builder doing client work, the practical meaning is simple. The setup you refined over your last three projects does not stay trapped in those projects. You package it once and every future engagement starts with your best system already loaded. That consistency is what separates a builder who charges a premium from one who reinvents the wheel every week.

Why Plugins Matter Specifically for Client Delivery

The core problem in agency-style work is that every project drifts. You set up a slightly different workflow each time because you are moving fast, and by the fifth client your delivery is inconsistent, hard to hand off, and impossible to teach. A plugin fixes that at the root. Your delivery system becomes a versioned artifact you install, not a set of habits you try to remember.

The second payoff is scale. The day you bring on a subcontractor or a second builder, you do not write a training document explaining your process. You give them the plugin. They install it and they deliver the way you deliver. That is how a one-person operation becomes a two-person operation without the quality dropping. The related mechanics are in [how to subcontract builders to scale](/blog/subcontract-builders-to-scale).

How to Build Your First Client-Work Plugin

Start with what you already repeat. Do not sit down to design a plugin in the abstract. Look at your last two client projects and list the things you did the same way both times: the questions you asked at intake, the format of your progress updates, the review you ran before shipping. Those repeated actions are your first plugin, already validated by real work.

1. Create a plugin directory with a manifest file that names the plugin and its version. This is the container everything else lives in.
2. Move your most-used slash commands into it - the intake prompt, the status-update prompt, the handoff-doc prompt. Anything you find yourself pasting in on every project belongs here.
3. Add one subagent that does a job you always want done but often skip when you are busy, such as a pre-delivery review that checks the build against the original scope.
4. Add a hook only if there is an action you genuinely want to run every time - formatting on save is the common one. Do not add hooks for their own sake; each one is something that fires automatically, so keep them deliberate.
5. Wire in the MCP servers you use on most projects, like your project tracker or your standard database connection, so a new project is connected on day one.

Keep the first version small. A plugin with three good slash commands and one review subagent is more useful than a sprawling one you never finish. You install it, use it on the next real project, and add to it only when you notice yourself doing something manually that should have been in the plugin. That feedback loop is the whole method.

Distributing a Plugin: Private, Team, or Public

Plugins are distributed through a marketplace file hosted in a Git repository. That single mechanism supports three very different plays depending on who you point at the repository. Understanding the three lets you get more mileage out of the same work.

• Private, for yourself: a repository only you can access. This is your personal delivery system, installed on every project you take. Most builders should start and stay here until the plugin is genuinely refined.
• Team, for subcontractors: a shared private repository your builders install from. Everyone delivers with the same commands, the same review subagent, and the same standards. This is the scaling move that keeps quality intact as you add people.
• Public, as a lead magnet: an open repository anyone can install from. A genuinely useful plugin that solves one narrow problem gets shared, and the person who installs it now associates you with the solution. This is a distribution asset, not a giveaway. The pattern is covered in [the builder's lead magnet - a free tool](/blog/builders-lead-magnet-free-tool).

The public route deserves a specific note. A plugin that does one thing well - say, a clean client-intake command set - is exactly the kind of free, useful, action-oriented resource that pulls the right people toward you. They install it, it works, and you are now the builder who made the thing they use every week. That is a warmer inbound path than any cold pitch.

Turning a Plugin Into Part of Your Offer

A plugin is not only an internal tool. It can be part of what you sell. When you hand off a build to a client, you can include a small plugin that lets their team run the standard operations of the system you built - a command to generate a report, a command to update a record, a review the tool runs before publishing. That handoff plugin makes your delivery feel like a real product, not a one-off.

It also creates a natural path to recurring revenue. A client using a plugin you gave them will ask for the next command, the next automation, the next connection. Maintaining and extending their plugin is a clean retainer story: you keep the system current as their process changes. The retainer framing is in [recurring revenue - retainer vs subscription](/blog/recurring-revenue-retainer-vs-subscription).

Price the plugin as part of the value, never as a line item for a config file. The client is not buying a package format. They are buying a delivery system that is consistent, documented, and extensible - one that would take them months to build and that most of your competitors cannot offer at all. That is a moat, and it deserves to be priced like one. The pricing discipline is in [value-based pricing - stop charging hourly](/blog/value-based-pricing-stop-charging-hourly).