Checkout & Payment Flow Skill

How this skill behaves (read first)

This is a generative skill. Checkout is the highest-stakes flow in the product — every bit of friction here is paid for in abandoned carts, and the defaults are leaky. The instinctive design — force account creation, show one long form, validate only on Submit, drop a blank promo box, surface the final price with no breakdown, and dead-end after payment — bleeds motivated buyers at the last step. This flow is a sequence — cart → identity → details/address → payment → processing → confirmation (booking swaps the front for search availability → select) — and which stages need investment depends on what's being bought. So this skill gates:

1. Establish what's being bought and for whom — that decides the stages, the fields, and the payment mix.
2. Apply the always-true core — the conversion-protecting patterns that hold for essentially every transaction.
3. Surface the context-dependent decisions (name fields, payment-method count, single- vs. multi-page, booking pickers, promo prominence) with trade-offs.

Then it hands the result to the audit lenses for validation (candidates; posture per docs/orchestration-policy.md). Composition (§9): checkout composes ux-inputs-and-forms, ux-buttons, and ux-selection-controls as core children, and defers confirmation-modal mechanics to ux-modals-and-dialogs and toast behavior to ux-notifications-and-toasts (peers — they own those sub-parts if reached). Under an existing design system, inherit color/type/spacing tokens.

Step 0 — Establish context before designing

Ask if not known; state the assumption if proceeding without an answer: