Package the Workflow, Not the Prompt

A new engineer joins your team on Monday. By Friday she’s shipping features, but every one of them comes out a little wrong — the agent edits files your linter forbids, skips the architecture review you always run, names things in a convention nobody told it about. She isn’t worse than you. She just doesn’t have your workflow, because your workflow doesn’t exist anywhere she can install it.

It exists in your muscle memory. It exists as three subagents you defined six months ago, a hook you copied off your old laptop, a slash command you keep meaning to document, and two MCP servers you configured once and forgot. To you it feels like a single fluid loop. To her it’s a scavenger hunt across your scrollback, and she will reconstruct maybe sixty percent of it before she stops asking and starts guessing.

The thing you’d reach to share with her is the prompt. The clever command you type, the one that kicks off a whole feature build. That instinct is wrong, and it’s the most expensive mistake on a team that’s serious about agentic coding. A prompt is the trigger. The trigger is the cheapest, most reproducible part of the whole thing. What makes your workflow good is everything wired behind the trigger — the subagents that split the work, the hook that blocks the dangerous tool call, the servers that give the agent reach. Ship the prompt without that wiring and you’ve handed her the steering wheel of a car with no engine.

Walk through what actually happens when you build a feature well. You don’t type one prompt and accept whatever comes back. You run a loop you’ve tuned by hand.

An explorer reads the codebase and reports what already exists. A reviewer checks the proposed change against your standards before any code lands. An architect decides how the piece fits the system instead of bolting it on. These are subagents — separate agent instances, each with its own context window and its own job — and the reason you use them is the whole point of this site. A single broad agent holds everything in one polluted context and averages across all of it. Split the work and each subagent stays narrow and deep on its slice. That split is context engineering: you’re manufacturing the focused, well-scoped context that a contextless model can’t produce on its own.

Behind those subagents sits a pre-tool-use hook — a deterministic gate that runs before the agent executes any tool call, inspects what it’s about to do, and can block it. Not a polite instruction in a rules file the model is free to ignore. An actual veto. When the agent tries to rm -rf a directory or write to a path you’ve marked off-limits, the hook stops it cold, every time, regardless of how the model is feeling about safety that day.

And the whole thing is fronted by one slash command — /feature — that takes the ticket as an argument and orchestrates the explorer, the architect, and the reviewer in the right order with the right handoffs.

That’s a genuinely good loop. Here’s the problem: it lives entirely on your machine, in your config, in your head. It is the single most valuable artifact your team has produced, and it has a bus factor of one. The day you move laptops you’ll spend an afternoon rebuilding it from memory. The day a teammate wants it, you’ll paste fragments into Slack and watch them assemble it wrong.

Here is the contrarian part, and I mean it literally. Most teams treat their agent setup as a personal-productivity concern — your dotfiles, your config, your business. That framing is the disease. A workflow that can’t leave your laptop intact isn’t a team standard. It’s a personal habit other people are forced to approximate.

The fix is not better documentation. Documentation of a workflow decays the instant the workflow changes, and yours changes weekly. The fix is to make the workflow a single installable, versioned unit — a plugin — and to distribute it through a marketplace your team already trusts.

A plugin bundles the subagents, the hook, the command, and the required MCP servers behind one manifest. Your teammate doesn’t reconstruct the loop. She installs it. When you improve the reviewer’s prompt, you cut a new version; she pulls it. The workflow stops being whatever each engineer happens to remember and starts being a thing the team owns, the same way it owns a shared lint config or a CI pipeline.

Here’s the actual shape. A plugin is a directory with a manifest and the components it ships. The manifest declares what’s inside and what the plugin depends on:

{
  "name": "feature-loop",
  "version": "1.4.0",
  "description": "Explorer/architect/reviewer subagents, a pre-tool-use safety gate, and the /feature command",
  "commands": ["./commands/feature.md"],
  "agents": [
    "./agents/explorer.md",
    "./agents/architect.md",
    "./agents/reviewer.md"
  ],
  "hooks": "./hooks/safety.json",
  "mcpServers": "./mcp.json"
}

The slash command is just a Markdown file with a body. The $ARGUMENTS token is where the ticket reference lands, and the body is the orchestration — the part that used to live only in your head:

---
description: Build a feature through the full explore → architect → review loop
---

You are running the feature loop for: $ARGUMENTS

1. Invoke the `explorer` subagent. Have it report every existing
   module, test, and convention relevant to this ticket. Do not
   write code yet.
2. Invoke the `architect` subagent with the explorer's findings.
   It decides where the change belongs and what it must not touch.
3. Implement the change following the architect's plan.
4. Invoke the `reviewer` subagent. It checks the diff against our
   standards. If it flags anything, fix and re-review before stopping.

The hook is the guardrail that travels with the command — and this is the piece teams forget. One pre-tool-use hook checks every tool call against a safety spec before it runs:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/check.sh"
          }
        ]
      }
    ]
  }
}

check.sh reads the proposed call on stdin, compares it to your spec — protected paths, banned commands, required-review globs — and exits with code 2 to block. That exit code matters: 2 is the one value that actually vetoes a tool call, while a plain non-zero exit just logs a warning and lets the call through. Get it wrong and you ship a gate that waves everything past. The exact spec is yours; the point is that it ships inside the plugin, so the safety arrives with the trigger instead of being something each engineer is trusted to remember to set up. Note CLAUDE_PLUGIN_ROOT: the plugin resolves its own paths so it works the same on every machine.

Finally the MCP servers — the external reach the loop assumes. If your reviewer queries your issue tracker and your explorer reads your internal package registry, those connections are dependencies of the workflow, not optional extras. Declaring them in the plugin means the loop arrives wired to the systems it needs:

{
  "mcpServers": {
    "tracker": {
      "command": "npx",
      "args": ["-y", "@your-org/tracker-mcp"]
    }
  }
}

Declaring the server is only half of it — you also want the command to pin which of its tools it may touch, and which it must never reach. This is the piece a pasted prompt silently inherits from whatever environment runs it. On your machine the explorer only ever called list_issues and get_issue; on your teammate’s machine the same tracker MCP also exposes close_issue and bulk_update, and nothing in her setup says those are off-limits. Same words, opposite blast radius. So the command pins both ends in its own frontmatter:

<!-- in the command's frontmatter -->
allowed-tools:
  - mcp__tracker__list_issues
  - mcp__tracker__get_issue
disallowed-tools:
  - mcp__tracker__close_issue
  - mcp__tracker__bulk_update

The two lists do different jobs, and the difference is the whole trick. allowed-tools pre-approves the read calls so the loop runs them without stopping to ask — it’s about friction, not safety, and it does not fence off anything you leave unlisted. disallowed-tools is the fence: it pulls the write tools out of the command’s reach while the loop runs, so they aren’t callable at all. The prompt body can say “do not modify any issue,” but that’s a request the model weighs. Removing the tool from the pool is a boundary the runtime enforces — and for a bound that has to hold no matter who runs it, back it with a deny rule in the plugin’s hook, the same veto that already guards your file paths. That’s what makes a loop safe to scatter across machines you don’t control: not a polite instruction that degrades under pressure, but a scope where the dangerous call has nothing to bind to.

That’s the whole bundle. The trigger, the orchestration, the guardrail, the reach, and the bounds on that reach — sealed into one versioned unit.

A marketplace is just a manifest listing plugins and where to fetch them. You point your team at it once, and every plugin in it becomes installable by name.

How the plugin travels is your call, and the choice maps to how much your code wants to stay private:

• owner/repo — public GitHub, the frictionless default for open or internal-open work.
• A private repo over SSH — the workflow stays inside the company; access rides on the keys engineers already have.
• A local path — for iterating on the plugin itself before you publish a version.

Then the install scope, which is the part people get wrong. There are three — user, project, and local — and the default is user. Install at user scope and the workflow follows you across every project on your machine: right for your personal defaults, wrong for a shared standard. Install at project scope and it’s written to enabledPlugins in the repo’s checked-in .claude/settings.json, so it follows the codebase — every engineer who clones that repo and trusts the marketplace inherits the identical loop. (local is the in-between: scoped to one repo but kept in your own un-committed settings, for trying a plugin out before you commit the team to it.) For a team standard you want project scope. That’s the line between “this is how I work” and “this is how we work here.”

There’s one gotcha that will make you think the whole thing is broken: plugins load at launch. Add the marketplace, install the plugin, and the new subagents and command won’t appear in your current session. Relaunch the agent — or run /reload-plugins — and they’re all there. Nobody warns you, and the first time it bites you’ll burn ten minutes convinced the install failed.

Run it forward. Your new hire clones the repo. She adds your marketplace and installs feature-loop at project scope — two commands. She relaunches. Now she has the explorer, the architect, and the reviewer. She has the pre-tool-use hook that will physically stop the agent from touching protected paths. She has /feature, and she has the tracker server it queries. She types /feature PROJ-214 and gets the same disciplined loop you’d run — not because she watched you do it, not because she read a wiki page, but because the loop is a thing she installed.

That is context engineering done at the level of the whole team. The gap this site keeps pointing at — the broad, fast, contextless agent on one side and the narrow, deep human who knows the codebase on the other — doesn’t close once and stay closed. It reopens for every new person and every new machine. Documentation lets it reopen. A versioned, installable workflow keeps it closed.

So stop copy-pasting your orchestration between machines and Slack threads. The clever prompt was never the asset. The asset is the loop behind it — and a loop you can’t hand to someone else, intact and versioned, isn’t a standard. It’s a story you tell about how you used to work.