ap2-agentic-payments/skills/ap2-human-not-present-flow/SKILL.md
Implement the AP2 human-not-present transaction flow — autonomous agent shopping with Intent Mandate authorization, constraint enforcement, and merchant escalation. Use when building autonomous agent purchasing that works after the user has left.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins ap2-human-not-present-flowInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetch live docs:
https://ap2-protocol.org/specification/ for the human-not-present flow specificationsite:github.com google-agentic-commerce AP2 human-not-present intent mandate for sampleshttps://ap2-protocol.org/topics/core-concepts/ for flow overviewhttps://ap2-protocol.org/roadmap/ and the latest spec to confirm the current support level for human-not-present (Intent Mandate) flows in the version you're targetingIn a human-not-present flow, the user provides authorization upfront and then leaves. The Shopping Agent acts autonomously within the constraints defined in the signed Intent Mandate.
Human-not-present is a first-class flow in current AP2 releases (added as the spec evolved beyond the initial human-present-only V0.1). Always verify the exact Intent Mandate fields and required signing semantics against the version you're targeting — fetch the live spec before implementing.
Phase 1: Intent Capture (User Present)
1. User → SA: Expresses shopping intent ("Buy me running shoes under $150")
2. SA → User: Repeats back understanding for confirmation
3. User: Confirms via in-session authentication
4. SA: Creates Intent Mandate from user's expressed intent
5. User → SA: Signs the Intent Mandate (hardware-backed)
6. User: May go offline
Phase 2: Autonomous Shopping (User Absent)
7. SA → Merchant: Presents Intent Mandate
8. Merchant: Evaluates whether they can fulfill within constraints
9. If uncertain → Merchant may force user confirmation (escalate)
10. If needs info → Merchant asks clarification (update Intent Mandate)
11. If can fulfill → Merchant creates Cart Mandate with offer
Phase 3: Authorization (May Require User)
12. SA: Evaluates Cart Mandate against Intent Mandate constraints
13. If within bounds → SA proceeds with payment
14. If outside bounds → SA rejects or escalates to user
15. Payment processing (similar to human-present Phase 4-6)
| Aspect | Human-Present | Human-Not-Present | |--------|--------------|-------------------| | User involvement | Throughout | Only at start (signing) | | Primary VDC | Cart Mandate | Intent Mandate | | Specificity | Exact items | Categories + constraints | | Agent autonomy | Low (user confirms) | High (agent decides within bounds) | | Risk level | Lower | Higher (needs more safeguards) |
The merchant can escalate from human-not-present to human-present:
The Shopping Agent must enforce Intent Mandate constraints:
If any constraint is violated, the agent must:
The Intent Mandate captures the user's actual words:
Fetch the specification for the current support level and exact Intent Mandate fields before implementing autonomous flows.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.