From adcp-client
Builds an AdCP retail media network agent that sells on-site placements, syncs product catalogs, tracks conversions, and reports performance. Fork a seller adapter and replace SWAP markers with backend calls.
How this skill is triggered — by the user, by Claude, or both
Slash command
/adcp-client:build-retail-media-agentThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A retail media agent sells on-site placements driven by a product catalog and reports conversion outcomes back to buyers. The fastest path is to **fork a worked seller adapter** and replace its `// SWAP:` markers with calls to your backend.
A retail media agent sells on-site placements driven by a product catalog and reports conversion outcomes back to buyers. The fastest path is to fork a worked seller adapter and replace its // SWAP: markers with calls to your backend.
| Specialism | Status | Fork this | Mock upstream | Storyboard |
|---|---|---|---|---|
sales-catalog-driven | stable | hello_seller_adapter_social.ts | npx adcp mock-server sales-social | sales_catalog_driven |
sales-retail-media | preview | Same | Same | placeholder |
The social fork target is the closest baseline because it already implements the catalog-driven surface (syncCatalogs, syncEventSources, logEvent) on top of SalesIngestionPlatform. Walled-garden social platforms and retail media networks share the same wire-level shape — buyer pushes catalogs and audiences, platform reports conversions, both close the loop via provide_performance_feedback. Apply the retail-specific deltas below.
For exact response shapes, error codes, and optional fields, docs/llms.txt is the canonical reference. The fork target stays in sync with the spec because PR #1394's three-gate contract fails CI when it drifts.
sync_catalogs, log_event, or provide_performance_feedbackNot this skill:
skills/build-seller-agent/skills/build-generative-seller-agent/sales-catalog-driven applies far beyond retail — restaurants (DoorDash sponsored listings), travel (Expedia accelerator), local commerce (Yelp). The storyboard tests the catalog + event surface, not the vertical.
Every retail-media agent hits the cross-cutting rules in ../cross-cutting.md plus the seller cross-cutting from ../build-seller-agent/SKILL.md — retail-media is additive on top of the seller baseline. The high-traffic ones for retail-media:
idempotency_key on sync_catalogs, sync_event_sources, log_event, provide_performance_feedbackcatalog_sync.${catalog_id}.${batch_id} as the stable operation_idlog_event field-name + UNIX-seconds + user_match projections (shared with sales-social CAPIs)sales-catalog-drivenWhat's different from the social baseline you forked:
supports_catalog: true and supports_conversion_tracking: true on each Product.create_media_buy accepts packages[].catalogs[] — references to previously-synced catalog ids. The seller renders the dynamic ad from the catalog row at serve time.sync_catalogs ingests product feeds (JSON / CSV / XML). Required per-row fields: product_id, title, price, image_url, category. Reject rows missing any of these with a structured error and surface the per-row failures in the response.sync_event_sources registers conversion endpoints — purchase, add_to_cart, page_view, search. Each event source has a source_id the buyer references on subsequent log_event calls.log_event accepts content_ids — the catalog row IDs the conversion attaches to. Counter-only responses pass the storyboard today; closed-loop attribution lands in 3.1.provide_performance_feedback accepts buyer optimization signals (clicked / not-clicked / converted / not-converted on specific impressions). Use it to close the bid-quality loop.sales-retail-mediaCurrently a v3.1 placeholder (empty phases in index.yaml); the protocol baseline is all that's enforced today. Claim the specialism to advertise intent. The forward-looking deltas on top of sales-catalog-driven:
publisher_properties and format_ids — search results, product detail page (PDP), homepage, category, offsite (display retargeting), in-store (DOOH).format_ids per product.publisher_properties.environment to disambiguate the rendering surface (web vs DOOH vs CTV) — the buyer's targeting overlays vary by environment.# Run the fork-matrix gate against the social baseline
npm run compliance:fork-matrix -- --test-name-pattern="hello-seller-adapter-social"
# Or validate your forked agent directly against the catalog-driven storyboard
adcp storyboard run http://127.0.0.1:3005/mcp sales_catalog_driven \
--bearer "$ADCP_AUTH_TOKEN" --include-bundles --json
The fork-matrix gate is the three-gate contract from docs/guides/EXAMPLE-TEST-CONTRACT.md: tsc strict / storyboard zero-failures / upstream façade.
For deeper validation: docs/guides/VALIDATE-YOUR-AGENT.md.
get_media_buy_delivery /reporting_period/start|end are ISO 8601 date-time strings, not date-only. Per-package billing rows require package_id, spend, pricing_model, rate, currency. sync_accounts rows require action: 'created' | 'updated' | 'unchanged' | 'failed'. See ../SHAPE-GOTCHAS.md and §6 for log_event field-rename + UNIX-seconds patterns shared with social CAPIs.
docs/migration-6.6-to-6.7.mddocs/migration-4.x-to-5.x.mdnpx claudepluginhub adcontextprotocol/adcp-client --plugin adcp-clientGuides forking a reference adapter to build an AdCP seller agent (publisher, SSP, retail media network) that sells ad inventory to buyer agents.
Provides guidance on paid advertising campaigns across Google Ads, Meta, LinkedIn, Twitter/X, and TikTok. Covers campaign strategy, audience targeting, bidding, and optimization.
Creates ads, copy, image prompts, video scripts, creative variations, and reviews compliance and launch plans. For full campaigns, copy-only, video, or Meta ad account checks.