UCP Shopper Skill

A lightweight buyer-agent skill for using merchant-published UCP to buy, order, book, reserve, schedule, or subscribe to products and services.

It is generic by design. It is not tied to one merchant, platform, payment provider, or protocol implementer.

Install

From this directory:

./install.sh

The installer refuses to overwrite an existing ucp-shopper skill or command unless it was previously installed by this package. Use ./install.sh --force only when you intentionally want to replace an existing local copy.

The installer copies the same skill into the common local agent locations:

• ~/.claude/skills/ucp-shopper
• ~/.agents/skills/ucp-shopper
• ~/.codex/skills/ucp-shopper

It also installs a small explicit command at:

• ~/.claude/commands/ucp-shop.md
• ~/.agents/commands/ucp-shop.md
• ~/.codex/commands/ucp-shop.md

For Codex installs, CODEX_HOME is respected when set.

Use

After install, ask naturally:

Buy me the golden serum from that skincare store.
Book me a morning train ticket to San Jose.
Reserve a table for two tomorrow night.

The skill tells the agent to check merchant UCP surfaces first when a merchant/provider is known or can be inferred. If the user gives a merchant name without a domain, the agent should resolve the official merchant-owned domain, then probe UCP before generic product search or manual checkout. If UCP is unavailable, the agent should fall back to normal safe web shopping behavior and say that UCP was not found.

For payment, the skill stays generic but includes provider playbooks. The agent should inspect the merchant's advertised payment or credential handlers, offer to help the buyer through the matching provider flow after consent, use a matching local wallet/CLI/MCP/tool when available, and involve the buyer only for explicit auth or approval steps. If shipping, contact, schedule, or option details are still missing, the agent should ask for those details while still naming the assisted provider flow it can run next. Payment-boundary responses should either offer to check/run the matching local provider capability after consent or say that capability was checked and is unavailable. After the buyer confirms the displayed total and selected payment path, the agent should keep going through setup/auth/approval/token creation and UCP completion until the merchant confirms the transaction or a concrete provider/tool blocker prevents it. Placeholder tokens in merchant docs are provider artifact shapes, not something the buyer should be asked to manually create or paste unless no matching local capability exists and the buyer explicitly chooses that fallback.

For Google Pay or AP2-style wallet approval, the skill treats a merchant-authorized approval URL as valid only when it is advertised by UCP for the current checkout. The agent should ask the buyer whether to proceed with the displayed total, open or present that approval URL after consent, let the buyer approve in the browser/wallet sheet, and verify the merchant order. The buyer should never be asked to paste a Google Pay token.

For first-time setup, the skill recommends Stripe Link CLI first because it supports Shared Payment Token rails when merchants advertise them. It also names concrete alternative capability families instead of a vague fallback: Google Pay/AP2, Visa Intelligent Commerce tokenized credentials, Mastercard Agent Pay agentic tokens, AgentCard or other virtual-card providers, PayPal, Apple Pay, bank/open-banking authorization, stablecoin/x402, BNPL, gift card, loyalty, account credit, or invoice/net terms. At checkout, the agent must filter choices to the handlers the merchant actually advertises through UCP. A concrete Stripe Link shared payment token playbook is included because many merchants may advertise that rail, but the core skill is still provider-neutral.

For hosts that support slash commands:

/ucp-shop buy the golden serum from example-merchant.com

Validate

./tests/validate-package.sh

Uninstall

./uninstall.sh