From adcp-client
Use when an AdCP compliance storyboard fails on an adapter you believe is spec-correct. Walks the rubric for deciding whether to fix the SDK, the adapter, or file upstream against the spec/storyboard.
npx claudepluginhub adcontextprotocol/adcp-client --plugin adcp-clientThis skill uses the workspace's default tool permissions.
Storyboards in `compliance/cache/<version>/` are assertions about adopter behavior. They are **not** the spec — they are tests authored against the spec. Storyboards drift. When one fails, the question is _which side is wrong_: the adapter, the SDK, or the storyboard itself.
Diagnoses and resolves spec-driven development issues: spec-reality gaps, dependency blocks, unclear requirements, failing tests, performance shortfalls, integration problems.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Storyboards in compliance/cache/<version>/ are assertions about adopter behavior. They are not the spec — they are tests authored against the spec. Storyboards drift. When one fails, the question is which side is wrong: the adapter, the SDK, or the storyboard itself.
This skill is the rubric for that decision. It exists because adopter-facing failures look identical regardless of cause, and the wrong-direction fix (changing the SDK to satisfy a storyboard that disagrees with the spec) compounds drift across the ecosystem.
storyboard run step fails on an adapter you believe satisfies the specexpect_error.code mismatch, context_outputs path did not resolve, or a response_schema failure on a response that round-trips through the generated TS typesNot this skill:
additionalProperties, missing required) on requests YOU sent — fix the requestFor any failing step, work the three checks in order. Stop at the first answer.
Open the schema the storyboard's step references (schemas/cache/<version>/<protocol>/<tool>-response.json or similar). Find the field, error code, or shape the storyboard expects.
adcontextprotocol/adcp. Cite the schema file path + line.If the spec defines the contract correctly, check whether the SDK's generated TS types and runtime validators match it. Read the relevant src/lib/types/*.generated.ts interface and confirm:
Every required field in the schema is present and non-optional in the TS type
Every discriminator (e.g., asset_type, status) is preserved (codegen sometimes strips oneOf discriminators when generating union types)
Format constraints (date vs date-time, URL pattern, idempotency_key length/pattern) are reflected in either the TS type or the framework's runtime validator
TS type matches spec, runtime validation works → continue to step 3.
TS type allows what spec rejects (or vice versa) → SDK bug. Fix the codegen or hand-fix the type. File against adcp-client.
Run the failing step in step mode (adcp storyboard step <agent> <storyboard_id> <step_id> --json) and inspect:
validations[] entry's pass/failCommon patterns:
context_outputs path did not resolve → the runner couldn't capture a value from your response under the expected path. Check whether the path matches what the spec defines (e.g., adcp#3892 captured rights_grant_id but the spec field is rights_id — storyboard was wrong).expect_error: code: X but your adapter returned a structured success response (e.g., AcquireRightsRejected with reason) → storyboard is asserting a thrown-error shape when the spec gives a first-class denial arm. Storyboard convention, not spec contract. File upstream.unresolved context variables from prior steps → the runner can't seed a variable the storyboard requires. Runner gap. File upstream against the storyboard runner.additionalProperties: false constraints, and oneOf arms can be loosened during codegen. Trust the JSON Schema as ground truth.response_schema validation passes but the step still fails → almost always a storyboard context_outputs or expect_error mismatch. Your response is correct; the test's assertion is wrong.expect_error: true + code: X) when the spec defines a structured denial arm → the storyboard is shipping a non-spec convention. The Rejected/Pending/Acquired union is the canonical shape; thrown error codes are for system failures (timeout, unreachable), not policy decisions.requires_scenarios: in a storyboard YAML lists prerequisite scenarios that must run first. Step-mode runs lose this dependency; use full storyboard run mode to verify, then re-step the failing piece for diagnostics.When the rubric points upstream, file with this template:
Title:
<storyboard_id>step<step_id>:<assertion>is non-spec —<canonical_shape>is the canonical wire shapeRepro: Run any spec-compliant adapter; show the failing step's
--jsonoutput.Root cause: Cite the spec schema file path + line that defines (or is silent on) the contract the storyboard asserts.
Fix: Update the storyboard YAML (or the spec doc-comment, if the spec is genuinely ambiguous).
Cross-link to the adapter PR that surfaced it. The storyboard maintainers see the convergent signal across adopters and can prioritize.
Real triage walks from this codebase:
acquire_rights step captured rights_grant_id via context_outputs. Spec field is rights_id. Cascading skip on next step. Resolution: spec → field is rights_id; storyboard is wrong; filed; closed.acquire_rights_denied step expected thrown code: GOVERNANCE_DENIED. Spec gives AcquireRightsRejected arm with reason. Resolution: storyboard is asserting a non-spec convention; filed upstream; adapter ships spec-correct shape.brand_rights/governance_denied storyboard step sync_governance skips because $context.governance_agent_url is unresolved; runner has no --context flag for full storyboard run mode. Resolution: runner gap, not adapter or spec gap; filed upstream.docs/guides/VALIDATE-YOUR-AGENT.md — adopter-facing validation flow that runs storyboards.docs/development/WIRE-VERSION-COMPAT.md — storyboard cache layout per spec version.