Plugins & Host Packs: Claude Code and Beyond

The emitter and the pack tree

The clean mental model is this: platform/ is the source of truth, and every host pack is a projection. I start from ten canonical roles, eighty-one skill sources that ship as eighty executable skills after the authored service-blueprinting flagship replaces its generated twin, seven authored templates, and the shared runtime registry of thirty sd_* tools. The compiler turns that inventory into release data, then the emitter lays it out for each host without changing the underlying practice.

That is why the pack tree matters. It prevents the usual integration drift where every client team hand-copies prompts, renames folders, tweaks configs, and silently forks the method. ASD refuses that pattern. The canonical inventory also carries 228 corpus resources, 10 role prompts, 38 registered artifact-kind contracts, and 39 catalog vocabulary rows. Those counts belong to the platform, not to any single host. A host pack either receives that inventory in a form it can load, or it receives an explicitly bounded subset. Nothing is implied.

The distribution story follows the same rule. The monorepo emits the installable targets, then scripts/publish-distribution-repos.mjs republishes them into two standalone mirrors: imehr/asd-plugin for coding-agent host packs and native Claude Code marketplace install, and imehr/asd-mcp for the standalone MCP server. Each mirror carries a provenance.json file that records the source commit it came from. If that provenance record is missing or stale, I stop trusting the copy immediately.

pnpm --dir suite install
node platform/compiler/compile.mjs
node platform/compiler/generate-skills.mjs
node platform/compiler/emit-packs.mjs --output /tmp/asd-packs

That four-command sequence is the foundation for everything else in this chapter. compile.mjs refreshes the canonical manifest and capability inventory. generate-skills.mjs renders the executable method skills. emit-packs.mjs projects the same practice into twelve targets: agy, buzz, claude-code, cli, codex, dsh, grok, kimi, mcp, omp, opencode, and pi. The output directory is deliberately disposable because emission is a build product, not a place for hand-maintained edits.

That regeneration rule is more than tidy engineering. It is how ASD keeps one method contract across many shells. A Claude plugin, a Kimi project mirror, and a bare CLI install should differ in loading shape, not in what counts as acceptable evidence, what the Critic can veto, or who owns the phase gate. The whole point of the emitter is to keep those invariants boring.

The twelve-target matrix

Once I accept that a pack is a distribution boundary rather than a second implementation, the twelve-target matrix becomes easy to read. Some targets bundle the full runtime with roles, skills, and MCP wiring. Some are prompt-only or neutral trees by design. Some are native installs. Some are repo conventions. The job is not to force them into false equivalence. The job is to say, precisely, what each one contains and what evidence backs it.

There is a pattern hiding in that table. Runtime-equipped packs carry the same MCP engine and, when the corpus roots are present, expose 30 tools, 228 resources, and 10 prompts. Prompt-only and neutral targets do not pretend otherwise. That is why I read pack docs as capability boundaries, not marketing pages. A target either bundles MCP wiring, or it does not. A target either has a native install story, or it asks me to copy source material into host discovery paths. Both are valid. Confusing them is how false claims get published.

Claude Code: native plugin and marketplace

Claude Code is the reference native plugin surface because it takes the whole practice in one install: ten role subagents, eighty executable method skills, the /asd orchestration command, and a vendored MCP server rooted at the plugin itself. I do not need a global asd binary. I do not need a sibling checkout. I do not need to guess where the server lives. The plugin carries its own wiring.

claude plugin marketplace add imehr/asd-plugin
claude plugin install asd@asd-platform

That two-command path is the canonical user install. It is the one I recommend whenever the marketplace is available, because it keeps distribution honest. The published plugin comes from the emitted mirror repository, and its provenance.json tells me exactly which source commit it was synced from.

From a source checkout, I can install the same plugin through the local packs tree. The important detail is that this is still a plugin install, not a manual copy masquerading as one. Claude Code reads the marketplace manifest from the emitted packs directory and installs the generated plugin by its marketplace id.

REPO=/path/to/agentic-service-designer
claude plugin marketplace add "$REPO/platform/packs"
claude plugin install asd@asd-platform

Inside the installed plugin, the critical file is the plugin-root .mcp.json. It points the host at the vendored server with a path that remains valid after installation:

{
  "mcpServers": {
    "asd": {
      "command": "node",
      "args": ["${CLAUDE_PLUGIN_ROOT}/mcp/bin/server.mjs"]
    }
  }
}

That one configuration block carries a lot of meaning. ${CLAUDE_PLUGIN_ROOT} resolves inside the installed plugin, so the vendored server is self-contained. No PATH registration. No global npm install. No “clone the monorepo next to your host” footnote. Claude gets a native plugin manifest under .claude-plugin/plugin.json, the ten role files under agents/, the eighty method skills under skills/, the orchestration shortcut at commands/asd.md, and the runtime bundle under mcp/. Everything arrives together.

There is still a fallback when the marketplace is unavailable: emit the packs, copy the Claude pack into a project, merge the copied .mcp.json with the project configuration, and replace ${CLAUDE_PLUGIN_ROOT} with a project-relative path. I use that only when I have to. It is a practical source-level fallback, but it is not the same claim as a native plugin install.

Role mentions and the /asd command

Once the plugin is installed, the surface I actually work with is simple. The canonical role mentions are @orchestrator, @researcher, @synthesizer, @mapper, @ideator, @prototyper, @measurer, @critic, @presenter, and @librarian. Those ten names are stable across the pack ecosystem. They are not cosmetic aliases. They encode authority, inputs, outputs, veto rights, and human checkpoints drawn from the shared role contract.

The /asd command is the orchestrator shortcut layered on top of that role roster. I use it when I want the platform to frame an engagement from a brief, route work in the expected order, keep every write on the tool path, and stop at the points where a human decision is required. I do not use it because I want magic. I use it because it is the shortest route to a disciplined loop.

/asd
@researcher run contextual-inquiry for lighthouse-transit and add every verbatim quote to the evidence register.
@mapper run journey-from-transcripts over the register and write the current-state journey-map artifact.
@critic review the journey-map before it can go final.

That sequence shows the core interaction model. The command frames. The role mentions make the active discipline explicit. The skills in the background provide the SOP layer. The vendored MCP server persists the work. The runtime gates do the enforcement. The host shell stays conversational, but the storage path is deterministic: evidence first, method run, artifact write, Critic pass or veto, factcheck, then a human phase advance. The role prompt cannot bypass that sequence.

The role distinctions stay sharp for a reason. The Researcher gathers evidence and provenance. The Mapper writes journeys, blueprints, ecosystems, and mental models. The Critic does not “give feedback” in the hand-wavy workshop sense; it writes evidence-cited review rows and can veto a draft back to revision. The Presenter assembles from final artifacts only. The Librarian checks corpus grounding and pack drift. Once I start thinking in those operational contracts, the host UI becomes much less mysterious.

That warning is load-bearing. A role mention is content plus host capability. It is never a blanket license to invent subprocess behavior. If the host can dispatch, the receipt must say so. If it cannot, ASD records the boundary explicitly rather than faking it. I would rather have an honest refusal than a slick demo that lies about what happened.

OpenCode, Codex, Kimi, Grok, AGY, OMP, and Pi

Claude Code is the cleanest native plugin story, but it is not the only useful surface. The other packs exist because real teams already live in different shells. The winning pattern is consistency at the practice layer and specificity at the host layer.

OpenCode gets a proper project adapter. I copy agent/ into .opencode/agents/, skills/ into .opencode/skills/, place the vendored runtime under a project-local mcp/, and merge the emitted opencode.json block that runs ["node", "mcp/bin/server.mjs"]. It is a strong fit when the team wants local project agents and an explicit MCP command array. The boundary is honest: emitted config and bundle are verified, but host loading stays unverified until an OpenCode-specific acceptance receipt says otherwise.

Codex receives repository conventions plus MCP, not a native plugin manifest. The important files are AGENTS.md, the emitted TOML block for .codex/config.toml, and the vendored server copied to a stable path such as .asd-mcp/bin/server.mjs. I like this shape because it meets Codex where Codex already works: repo rules in plain text, runtime tools through MCP. I do not overclaim it. The Codex pack does not promise native subagent discovery just because the role prompts exist.

Kimi is a project mirror under .kimi-code/. It carries the same ten agents, the same eighty skills, the same vendored MCP bundle, and a project-level mcp.json that points at .kimi-code/mcp/bin/server.mjs. The extra operational requirement is workspace trust. If the project has not been trusted, the pack is present on disk but not yet in a state where the host can be treated as live.

Grok is intentionally lighter. It ships prompt files only. No bundled MCP. No runtime. If I want Grok to work against the ASD engine, I pair the role prompt with a separate MCP client that points at the standalone mcp pack. That is still useful. Prompt-only does not mean worthless. It means exactly what it says.

AGY is narrower still. Its payload is a review-session contract that teaches the AGY or Herdr lane how to behave like an ASD Critic: inspect evidence, read acceptance rules, respect host capability boundaries, and keep human authority explicit. It is excellent for adversarial review. It is the wrong thing to call a native AGY plugin, because it is not one.

OMP and Pi are neutral trees. They ship canonical role and skill source material in host-friendly folder layouts, but no runtime bundle and no MCP wiring. I use them when I want to port the practice into a host whose loading rules I control separately. They are deliberately conservative. The pack gives me the content and refuses to pretend the runtime question is solved.

Beneath all of those host adapters sit the two lowest-level surfaces: the standalone CLI and the standalone MCP server. When I need to prove the loop itself rather than the host sugar around it, I drop to one of those layers first.

PACK=/tmp/asd-packs/cli
mkdir -p "$HOME/.local/bin"
ln -sf "$PACK/asd" "$HOME/.local/bin/asd"
export PATH="$HOME/.local/bin:$PATH"
export ASD_WORKSPACE="$(mktemp -d)/projects"
asd project-create --name "Metrovale Access" --client "Fictional composite" \
  --sector public-transport --service "step-free journeys" --phase discover
PROJECT_ID=metrovale-access-12345678
asd evidence-add --projectId "$PROJECT_ID" --source interview-01 --kind quote \
  --body "I cannot tell whether the lift is working before I travel."

I keep that CLI loop in the chapter because it exposes the shared engine with nowhere to hide. The same gate logic appears here that later surfaces through Claude Code, OpenCode, Kimi, Codex, or a standalone MCP client. Evidence kinds are still exactly quote, telemetry, and document. A failing artifact write still persists as draft with machine-readable failure rows. A Critic pass still needs an evidence-cited proposal row. A veto still needs a defect and a fix. The host can change. The contract cannot.

What verified means, and what it does not

This is where most agent-platform documentation goes soft. ASD is stricter. It separates three proof layers that many teams lazily collapse into one sentence.

First layer: emission. Emission proves the compiler generated the expected files and pack tree from the canonical source. That is what Figure 18.1 shows. It tells me the build product exists and that the generated layouts line up with the declared targets. Emission alone does not prove a native host loaded anything.

Second layer: pack-local execution. For six emitted MCP bundles — buzz, claude-code, codex, kimi, mcp, and opencode — the current release matrix has fresh disposable stdio evidence. In each case the evidence covers initialize, the full set of 30 tools, 228 paginated resources, 10 prompts, a representative project-to-evidence-to-artifact-to-evidence-cited-review-to-factcheck workflow, and clean stderr with no ambient executable fallback. That is strong proof. It is still only pack-local proof.

Third layer: native host execution. This is the layer that says a particular product version, in a particular integration mode, loaded the pack and exercised the behavior being claimed. Claude marketplace installation is one example. The DSH receipt is another. A BUZZ live channel walkthrough is another, but only for the exact bounded slice it captured. Host receipts are where I learn what really happened in the shell a human will use.

The practical consequence is simple: I never let a lower layer impersonate a higher one. A pack-local MCP initialize transcript does not become proof that BUZZ delivered a mention to the right runtime. A generated plugin manifest does not become proof that Claude executed a research session. A DSH compatibility pointer does not become proof that every provider and every chat mode is supported. I stay literal.

REPO=/path/to/agentic-service-designer
claude plugin validate "$REPO/platform/packs/claude-code"

claude plugin validate is a good example of the distinction. It is meaningful. It proves the emitted Claude pack matches the host's structural expectations for a plugin. It is also not a session receipt. Validation tells me the door is shaped correctly. It does not tell me a user walked through it and completed a real loop.

That discipline also keeps the language around BUZZ and DSH clean. BUZZ Article 37 shows an observed live slice: a private channel, genuine orchestrator reply and relay handoffs, and a Canvas index. It does not prove MCP persistence, durable Critic verdict rendering, reload or cleanup, or ACP spawn. DSH has a pinned receipt for its verified profile, slot set, test suite, and loopback Studio smoke. It does not claim every provider, chat surface, or external MCP-client combination under the sun. The boundaries are not weaknesses. They are the proof that the platform is being documented honestly.

Choosing a surface per engagement

So which surface should I choose? I start from the engagement constraint, not from the shininess of the host. If I need a native collaborative coding shell with the full pack intact, I choose Claude Code. If I need a machine-facing runtime for another client, I choose MCP. If I want the rawest possible proof path or CI integration, I choose the CLI. If a team already works inside a different host, I install the corresponding adapter and keep the evidence claims narrow.

If I boil that decision down to one sentence, it is this: choose the thinnest surface that still matches the work you need to do, then verify the exact layer you plan to rely on. For teaching, debugging, and CI, I often start with the CLI or standalone MCP because the receipts are easiest to read. For live design work inside a coding agent, Claude Code is the reference because the whole pack lands intact. For adjacent hosts, I treat the emitted adapter as source material plus bounded evidence, then I earn stronger claims only by running the host-specific acceptance path.

That habit keeps the platform honest. It also makes it much easier to extend. Once I understand that a pack is just a deterministic projection of one canonical practice, I stop arguing about which host is “the real one.” The real one is the practice contract. The host is the shell I can validate today.