Build a Plugin for Your Team, Not Just Yourself

You built a slash command that saves you twenty minutes a day. Great. But your teammate is still doing the same task by hand, and the new hire on the platform team has never heard of it.

This is the gap between personal automation and organizational leverage. A /deploy skill tucked inside your .claude/ directory helps exactly one person. A properly packaged plugin — with parameterized context files, MCP connections, and marketplace distribution — helps every engineer on your team the moment they type /.

This guide walks through the complete lifecycle: spotting the right workflow to abstract, building the skill, parameterizing it so any engineering manager can customize the output, packaging it with the correct directory structure, and shipping it through a marketplace your team already uses.

The best plugin candidates share three traits. They're frequent — someone on the team runs the workflow at least weekly. They're variable — the inputs change, but the structure stays the same. And they're high-context — they require knowledge that lives in people's heads rather than in documentation.

Stand-ups, sprint briefs, incident post-mortems, onboarding checklists, release notes — these are all workflows where the skeleton is predictable but the details shift every time. The worst candidates are one-off tasks or anything that genuinely requires novel judgment each run.

Let's ground this in something tangible. Your engineering org has six teams. Every Monday, each EM writes a brief covering what shipped last week, what's in progress, and what's blocked. They pull from GitHub PRs, Jira tickets, and Slack threads — all manually. It takes 30-45 minutes per manager per week.

This is a textbook plugin candidate: frequent, variable, high-context. The output format is stable (a summary document), but the inputs are unique per team and per week. Here's how to build /team-brief from scratch.

This is where most plugin builders cut corners, and where the leverage either materializes or falls apart. A context file is a per-team (or per-user) configuration that the skill reads at runtime to customize its behavior. Without it, you end up with either a plugin so generic it's useless or one so specific it only works for the team that built it.

The key insight: context files are not settings files. Settings control behavior ("use bullet points"). Context files carry domain knowledge ("our repos are api-gateway, user-service, and billing-core, and our Jira project key is PLAT"). This distinction matters because settings can have sensible defaults, but context requires input from the person who knows the team.

Each team member who uses the plugin copies the template, fills in their team's specifics, and saves it as context/teams/<team-name>.yaml. The skill reads the right file based on the argument passed: /team-brief:generate-brief platform loads context/teams/platform.yaml.

This pattern — a single skill backed by per-team context files — is how you get org-level coverage from a single codebase. The plugin never needs to know how many teams exist or what their repos are called. It just reads whatever context file it's pointed at.

A team brief plugin is useless without data. MCP (Model Context Protocol) servers give your plugin authenticated access to external systems — GitHub, Jira, Slack, databases — without embedding credentials in the plugin itself.

The .mcp.json file at your plugin root declares which MCP servers the plugin needs. When someone installs the plugin, Claude Code connects to these servers using the credentials already configured on their machine.^[1]

Before you push a plugin to any marketplace, test it locally with the --plugin-dir flag. This loads your plugin directly without requiring installation, so you can iterate fast.

Once your plugin is tested and solid, you have two distribution paths. For internal teams, the simplest approach is a team marketplace — a Git repository that serves as a plugin registry. Add your plugin directory, and anyone on the team can install it directly.

For broader distribution, submit to the official Anthropic marketplace through the submission forms at claude.ai/settings/plugins/submit or platform.claude.com/plugins/submit.

Either way, versioning matters. Use semantic versioning in your plugin.json. Bump the patch version for bug fixes, minor for new features that don't break existing context files, and major for changes that require users to update their configuration.

The /team-brief example is just one application of this pattern. Once you've built one plugin with parameterized context files, the same architecture applies everywhere. Here are workflows that teams have successfully turned into shared plugins using the exact same approach — a SKILL.md with clear instructions, context files that carry team-specific knowledge, and MCP connections for external data.

You don't need to build the whole thing at once. Start with a personal skill in .claude/commands/ that solves your own problem. Run it for a week. Pay attention to what you hardcode and what changes between runs. Those variable parts become your context file schema.

Once the skill works reliably for you, spend an hour converting it to a plugin: create the directory structure, write the manifest, and move the skill into skills/. Test it with --plugin-dir. Hand it to one teammate and watch where they get stuck — that's where your template file needs better comments.

The gap between a personal shortcut and a team-wide plugin is smaller than it looks. Most of the work is the skill itself. Packaging and distribution are mechanical steps. The real investment is in context file design, and that investment pays back every time a new team picks up your plugin and is running in five minutes instead of building their own from scratch.