ASD Plugin Distribution

Generated artifacts — synced from the canonical monorepo the-agentic-service-designer at commit 5acee17c1949. Do not edit pack files by hand; change the source repository and re-publish.

This repository is mirrored at sammozaffari/asd-plugin; both copies are pushed from the same publish run and carry identical content.

Installable coding-agent packs for the Agentic Service Designer (ASD): a Service Design practice encoded as a portable runtime — 10 role agents, 74 executable method skills, a 29-tool SD engine (vendored MCP server), typed artifact contracts, Critic review, and human phase gates.

---

1. What is Agentic Service Design?

ASD treats a service design engagement as an evidence-gated pipeline rather than a chat. Every claim traces to captured evidence, every method produces a typed artifact, every artifact passes a Critic review before it becomes final, and phase transitions require an explicit human approval receipt. The same loop runs identically on every supported host because the state lives on disk in a portable project store, not in the host.

The practice loop:

1. Create/open a project and capture quote, telemetry, or document evidence.
2. Run a method (sd_method_run) to get its executable SOP with role-attributed steps and acceptance rules.
3. Write a typed artifact (sd_artifact_write). Schemas are closed: unknown fields are rejected, and dangling evidence references fail hard.
4. Send it to the Critic (sd_review). A pass promotes the artifact from draft to final; a veto writes an evidence-cited review-veto-log and the candidate stays draft.
5. Fact-check (sd_factcheck) — CI and release scripts treat a false result as exit 1.
6. Advance the phase only at the human gate (sd_phase_advance) with an approval receipt. Agents prepare decisions; they cannot silently authorize them.

Project phases: discover → define → develop → deliver. Method phases: research, synthesis, ideation, prototyping, delivery, measurement.

2. What is inside

Directory	Host	Payload	Verified install
claude-code/	Claude Code	Native plugin: 10 subagents, 74 skills, /asd command, vendored 29-tool MCP server	yes — marketplace add + install + validate
codex/	Codex CLI / desktop app	AGENTS.md project conventions, .codex/config.toml MCP registration, vendored MCP server	config-level; desktop build not live-verified
kimi/	Kimi Code	Project .kimi-code/ tree: agents, skills, mcp.json, AGENTS.md	live (Kimi 0.37, workspace trust required)
opencode/	OpenCode	10 agent files, 74 skills (<name>/SKILL.md), vendored MCP server, opencode.json	structural
omp/, pi/	Oh My Pi / Pi	Neutral trees: agents/<role>/instructions.md, skills/<skill>/SKILL.md	neutral source; native loading unverified
grok/	Grok	Ten role prompt adapters only	prompt-only
agy/	AGY / Herdr review lane	review-session.md Critic-review contract	prompt-only

Canonical counts at publish time: 29 tools, 74 methods from 75 sources, 32 artifact-kind schemas, 38 catalog rows, 226 corpus resources.

Every pack that wires the MCP engine vendors the same self-contained server (mcp/bin/server.mjs, node builtins only) and bundles the knowledge corpus next to it — no PATH setup, no npm install, no sibling checkout.

3. Install

3.1 Claude Code (native plugin)

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

Verify:

claude plugin details asd     # expect Skills (75), Agents (10), MCP servers (1)

The plugin root carries .claude-plugin/plugin.json, .mcp.json (node ${CLAUDE_PLUGIN_ROOT}/mcp/bin/server.mjs), agents/, skills/, commands/asd.md. Manual-copy alternative: copy agents/ skills/ commands/ into your project's .claude/, then copy mcp/ + .mcp.json to the project root and replace ${CLAUDE_PLUGIN_ROOT} with ..

3.2 Codex CLI / Codex desktop app

cp -R codex/. /path/to/your/project/

Ships AGENTS.md (project conventions), .codex/config.toml ([mcp_servers.asd]), and the vendored mcp/. The desktop app reads the same ~/.codex/config.toml registration as the CLI; the project-level .codex/config.toml scopes it to one workspace. Desktop execution is structurally supported but not live-verified.

3.3 Kimi Code

mkdir -p .kimi-code && cp -R kimi/. .kimi-code/

Mirrors a project-level .kimi-code/ tree (agents/, skills/, mcp.json, AGENTS.md). Approve Trust this folder when prompted — project-level MCP servers require workspace trust.

3.4 OpenCode

mkdir -p .opencode/agents .opencode/skills
cp -R opencode/agent/. .opencode/agents/
cp -R opencode/skills/. .opencode/skills/
cp -R opencode/mcp .opencode/mcp

Merge opencode.json entries if you keep project config.

3.5 Oh My Pi (OMP) / Pi — neutral trees

mkdir -p .omp/agents .omp/skills
cp -R omp/agents/. .omp/agents/
cp -R omp/skills/. .omp/skills/

Native host loading is unverified by design; these trees are source material.

3.6 Grok — prompt adapters

grok/prompts/*.md carries the ten role prompts. For runtime tools configure an independent MCP client with the standalone asd-mcp repository.

3.7 AGY review lane

agy --file agy/review-session.md --mode plan

Review contract only — no plugin, no runtime tools.

4. Tutorial — Metrovale Council housing repairs

A complete engagement you can run in any MCP-wired host (Claude Code shown; the tool calls are identical everywhere). Scenario: repair backlogs are damaging tenant satisfaction and the council wants a service design pass on the repairs journey.

If you are in Claude Code, drive it conversationally — the /asd command or the orchestrator agent will make these exact tool calls. Sections 4a–4e show the underlying calls so you can see the machinery.

4a. Create the project

Tell the agent: "Start an ASD project for Metrovale Council's housing repairs service." Under the hood:

{"tool": "sd_project_create",
 "args": {"name": "Housing Repairs", "client": "Metrovale Council",
          "sector": "local-government", "service": "housing-repairs"}}

On disk: <workspace>/<slug>-<id>/ with project.json, artifacts/, evidence/, renders/, sops/. Projects default to ~/.asd/projects; set ASD_WORKSPACE to relocate.

4b. Capture evidence (minimum three records)

{"tool": "sd_evidence_add", "args": {"projectId": "<id>", "kind": "quote",
 "source": "tenant-interview-01", "body": "Repairs take weeks to get acknowledged"}}
{"tool": "sd_evidence_add", "args": {"projectId": "<id>", "kind": "quote",
 "source": "tenant-interview-02", "body": "No single point of contact for repairs"}}
{"tool": "sd_evidence_add", "args": {"projectId": "<id>", "kind": "telemetry",
 "source": "crm-export", "body": "Median first-response time 19 days"}}

Evidence ids are content hashes — keep them; artifacts must cite them.

4c. Run a method SOP

{"tool": "sd_method_run", "args": {"projectId": "<id>", "methodId": "aeiou-coding"}}

Returns the method contract: owner role (synthesizer), book provenance (18-universal-methods-of-design ch.05), and acceptance rules (min-nodes: 3, min-evidence-per-node: 2, non-empty theme field). The SOP also names the output kind: affinity-cluster-set.

Not sure which methods exist? sd_method_list (optionally --phase research) or plain language: ask the librarian role.

4d. Write the typed artifact

Check the closed schema first (sd_schema_get --kind affinity-cluster-set), then:

{"tool": "sd_artifact_write", "args": {"projectId": "<id>", "methodId": "aeiou-coding",
 "title": "AEIOU clusters",
 "nodes": [
   {"id": "n1", "label": "Latency",
    "evidence": [{"evidenceId": "<hash1>"}, {"evidenceId": "<hash3>"}],
    "fields": {"cluster": "responsiveness", "theme": "slow response"}},
   {"id": "n2", "label": "Ownership",
    "evidence": [{"evidenceId": "<hash2>"}, {"evidenceId": "<hash1>"}],
    "fields": {"cluster": "accountability", "theme": "fragmented ownership"}},
   {"id": "n3", "label": "Backlog growth",
    "evidence": [{"evidenceId": "<hash3>"}, {"evidenceId": "<hash2>"}],
    "fields": {"cluster": "demand", "theme": "rising demand"}}],
 "edges": []}}

Expect the engine to be strict: unknown fields rejected, every cited evidenceId must resolve, acceptance minimums enforced. Failures come back as machine-readable rows — fix and resubmit. The artifact lands as status: "draft".

4e. Critic review → final → factcheck → human gate

{"tool": "sd_review", "args": {"projectId": "<id>", "artifactId": "<aid>",
 "verdict": "pass",
 "rows": [{"rowKind": "proposal", "severity": "low", "check": "clusters-grounded",
           "result": "pass", "message": "All clusters cite captured tenant evidence",
           "evidenceId": "<hash1>"}]}}

Rules: a pass requires at least one evidence-cited row and cannot carry defect rows; a veto requires defect rows each with a fix and demotes the artifact. On pass with acceptance satisfied, status flips to "final".

{"tool": "sd_factcheck", "args": {"projectId": "<id>"}}

Exit-fails while anything is still draft or failing integrity.

{"tool": "sd_phase_advance", "args": {"projectId": "<id>", "toPhase": "define",
 "idempotencyKey": "gate-discover-1",
 "approvalReceipt": {"receiptId": "gate-discover-1", "decision": "approve",
                     "rationale": "Discover evidence and synthesis complete",
                     "approvedBy": "service-lead",
                     "approvedAt": "2026-08-22T12:00:00Z"}}}

The gate re-verifies that every design artifact is final before moving discover → define → develop → deliver. The receipt is stored in the project.

4f. What you have at the end

A portable project folder where every insight cites captured evidence, every artifact passed the Critic, the factcheck passes, and the phase transition carries a named human approval — ready to hand to the next phase, render (sd_export_artifact / sd_export_report), or audit.

5. Daily-driver cheat sheet

I want to…	Ask for / call
See available methods for a phase	sd_method_list
Get a method's SOP + acceptance rules	sd_method_run
Check an artifact schema before writing	sd_schema_get --kind <kind>
Browse the corpus canon	sd_knowledge, or MCP resources asd://books/*, asd://articles/*
Render a deliverable	sd_export_artifact, sd_export_report
Coordinate roles on multi-artifact work	sd_orchestration_plan/status/dispatch/handoff
Keep shared scratch state	sd_canvas_add/list/remove
List templates	sd_template_list / sd_template_get

CLI users: the same tools exist as asd <kebab-case> subcommands (sd_project_create → asd project-create).

6. Boundaries (read before relying on it)

• Host execution is proven for Claude Code marketplace install + vendored server boot, and for Kimi project-level MCP. OpenCode/Codex wiring is structural; omp/pi/agy/grok are prompt-or-neutral by design.
• ACP collaboration is record-only/fail-closed: no live agent spawning.
• Case studies in the corpus are labelled synthetic or illustrative unless a release receipt ties them to an observed run.

7. Provenance and license

Generated from the canonical monorepo the-agentic-service-designer (commit 5acee17c1949) by scripts/publish-distribution-repos.mjs; provenance.json in this repo records the sync. The knowledge corpus is maintained as a Service Design learning resource. See the source repository for receipts and evidence boundaries.