From web-commerce
Understand and extend the thin shared contract every provider track implements — the payment-lifecycle interface plus advertised capabilities. Use when adding a provider, wiring a track to the contract, or deciding what belongs in the shared seam vs a track. The ONLY cross-provider abstraction; catalog/cart/inventory are track-specific.
How this skill is triggered — by the user, by Claude, or both
Slash command
/web-commerce:payment-lifecycle-contractThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The single cross-provider abstraction in `web-commerce`. It exists because Stripe/Square/Shopify sit at different layers — a unified "commerce" interface leaks (Vercel deleted ~145K LOC learning this). The seam is deliberately **thin**: only what all three genuinely share. It is modeled on Medusa's `AbstractPaymentProvider` + Saleor's advertised-capabilities pattern.
The single cross-provider abstraction in web-commerce. It exists because Stripe/Square/Shopify sit at different layers — a unified "commerce" interface leaks (Vercel deleted ~145K LOC learning this). The seam is deliberately thin: only what all three genuinely share. It is modeled on Medusa's AbstractPaymentProvider + Saleor's advertised-capabilities pattern.
templates/shared/)PaymentProvider (payment-provider.ts) — id, capabilities, createCheckout(), handleWebhook(), and the capability-gated authorize/capture/refund/cancel (present only when the provider supports them).ProviderCapabilities (capabilities.ts) — what a track can honestly do, so callers never assume a uniform set. Shopify declares checkout:'hosted', authorizeCapture:false and omits the gated methods.CommerceEvent, CheckoutHandle, Money, PaymentStatus (commerce-types.ts) — the shared value types.safeSignatureEqual, WebhookVerifier (webhook-verify.ts) and IdempotencyStore (idempotency-store.ts).Catalog, cart, inventory, and order shapes. These differ fundamentally per provider (Shopify owns the catalog; Stripe has none; Square couples it to POS). They live in each track with shared conventions, not shared code.
| checkout | authorizeCapture | refunds | catalogSourceOfTruth | posReconciliation | |
|---|---|---|---|---|---|
| Stripe | both | true | true | app | false |
| Square | both | true | true | provider | true |
| Shopify | hosted | false | false | provider | false |
PaymentProvider with an honest capabilities object.createCheckout returning a CheckoutHandle (hosted url or embedded clientSecret).handleWebhook — verify constant-time BEFORE parse, normalize to CommerceEvent (see webhook-hardening).assertCapability guard callers.shared/.Widening the shared contract to hold catalog/cart/checkout "so all providers share it." That is the exact regression the three-track design exists to prevent.
Guides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
Dispatches multiple subagents concurrently for independent tasks without shared state. Use when facing 2+ unrelated failures or subsystems that can be investigated in parallel.
npx claudepluginhub mcorbett51090/ravenclaude --plugin web-commerce