A Personal Slash Command Helps One Person. A Plugin Compounds.

You wrote a slash command that saves you twenty minutes a day. Good. Your teammate is still doing the work by hand. The new hire on the platform team has never heard of the file.

That is the gap between a personal shortcut and organizational leverage. A /deploy skill living in your .claude/ directory is a private dotfile. A packaged plugin — parameterized context files, declared MCP connections, marketplace distribution — runs for every engineer the moment they install it. Same skill. Different topology.

This is the full lifecycle. Spotting a workflow that survives the abstraction. Building the skill. Pulling the team-specific values out into context files. Wiring MCP without shipping credentials. Versioning, distribution, and the failure modes that kill adoption before the second team installs it.

Three properties separate plugin candidates from workflows you should leave as personal shortcuts. Frequency — someone runs the workflow at least weekly. Variable inputs, stable structure — the data shifts, the skeleton holds. High-context — the work depends on knowledge that lives in heads, not in documentation.

Monday standup briefs. Sprint summaries. Incident post-mortems. Onboarding context dumps. Release notes. Each one has a predictable skeleton and inputs that change every run. The bad candidates are one-off migrations and anything that requires a new judgment call each time. If the human has to think hard mid-flow, the plugin is not absorbing the task — it is just dressing it up.

Make this concrete. The org has six teams. Every Monday, each EM writes a brief covering what shipped, what is in progress, what is blocked. They pull from GitHub PRs, Jira tickets, Slack threads — all by hand. Thirty to forty-five minutes per manager per week.

The workflow checks every box. Frequent. Variable inputs, stable output. High-context. Different teams, different repos, same operation. This is what /team-brief looks like rebuilt as a plugin from scratch.

This is where most plugins die quietly. A context file is a per-team configuration the skill reads at runtime. Without one, you ship either something so generic it produces useless output or something so specific only the author's team can run it.

We shipped the wrong version first. The initial team-brief plugin had the GitHub org name baked into SKILL.md. Three days in, an engineer from another org tried to install it, got opaque errors, and walked away. The fix was twenty minutes of code. The reputational damage took weeks to undo. People do not return to a tool that failed them on first contact.

The distinction that matters: context files are not settings files. Settings control behavior — "use bullet points," "include velocity." Context files carry domain knowledge — "our repos are api-gateway, user-service, billing-core, and our Jira project key is PLAT." Settings have defaults. Context cannot. The team owner has to provide it because nobody else has the information.

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

One skill. N context files. N teams covered. The plugin never knows how many teams exist or what their repos are called. It reads whatever context it is pointed at and operates on it. That is the architecture that makes a plugin survive past the first install.

A team brief plugin without data sources is a template generator. MCP (Model Context Protocol) servers give the plugin authenticated access to GitHub, Jira, Slack, databases — without embedding credentials in the plugin itself.

The .mcp.json file at the plugin root declares which MCP servers the plugin requires. When someone installs, Claude Code connects to those servers using credentials already configured on their machine.^[1] The plugin never sees a token. The user authenticates once, the MCP server handles every subsequent call.

Push a plugin to a marketplace before testing it locally and you will be debugging in front of an audience. The --plugin-dir flag loads your plugin directly from disk — no install, no marketplace round-trip, fast iteration.

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

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

Either way, versioning is enforcement. Use semantic versioning in plugin.json. Patch for bug fixes. Minor for new features that do not break existing context files. Major for any change that requires users to update their configuration. Get this wrong and every release breaks installs that were working yesterday.

The /team-brief example is one application of the architecture. Once you have built one plugin with parameterized context files, the same shape applies everywhere. Below are workflows teams have packaged using the same approach: a SKILL.md with explicit instructions, context files carrying team-specific knowledge, MCP connections for external data.

The honest counterpoint: not every workflow earns a plugin. Tasks that run once a quarter, or that require a fresh judgment call at every step, generate maintenance overhead that exceeds the savings. The format works when the structure is stable and the variable is the input data — not the decision-making.

Do not build the whole package on day one. Start with a personal skill in .claude/commands/ that solves your own problem. Run it for a week. Watch what you keep hardcoding and what shifts between runs. The variable parts are the schema for your context file.

Once the skill works for you, spend an hour converting it: create the directory, write the manifest, move the skill into skills/. Test with --plugin-dir. Hand it to one teammate and watch where they get stuck — that is where your template comments need to be sharper.

The gap between a personal shortcut and a team-wide plugin is smaller than it looks. The skill itself is most of the work. Packaging is mechanical. The investment that pays back is context file design. Get it right and a new team installs the plugin and runs in five minutes instead of building their own from scratch. That is the leverage.