Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Uxcel-Lab/product-skills --skill checkout-paymentgit clone --depth 1 https://github.com/Uxcel-Lab/product-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/uxcel-lab/product-skills/checkout-payment)<a href="https://agentmods.dev/skills/uxcel-lab/product-skills/checkout-payment"><img src="https://agentmods.dev/badge/skills/uxcel-lab/product-skills/checkout-payment/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/uxcel-lab/product-skills/checkout-payment"><img src="https://agentmods.dev/badge/skills/uxcel-lab/product-skills/checkout-payment.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00126 | $0.03354 |
| Opus 5 | $0.00063 | $0.01677 |
| Sonnet 5 | $0.00025 | $0.00671 |
| Haiku 4.5 | $0.00013 | $0.00335 |
Grade A, and why
ux-checkout-payment scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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:
- Establish what's being bought and for whom — that decides the stages, the fields, and the payment mix.
- Apply the always-true core — the conversion-protecting patterns that hold for essentially every transaction.
- 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:
- What's being bought? One-time purchase (physical goods → shipping address + cart summary; digital → no shipping) vs. booking/reservation (date/time/availability is the core, front-loaded by a search step) vs. subscription (recurring terms, trial-to-paid, must state billing cadence clearly). This reshapes which stages exist.
- Platform — mobile tightens everything: input steppers over dropdowns for quantity, single name field, contextual numeric keypads, OTP autofill, ≥48×48dp touch targets spaced ≥8dp. Desktop has room for labels and side-by-side summary.
- Audience / region — international means single name field, country-first address hierarchy, and a region-appropriate payment mix (credit cards are not universal — weak in Germany, China, etc.). Domestic single-region relaxes these.
- Account model — does the product genuinely need an account to function, or is that just data collection? This decides how hard guest checkout is fought for.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 143 lines · 126 tokens per session scan A c8c2c9a02fc7
ux-checkout-payment is a skill published in the GitHub repository Uxcel-Lab/product-skills (10 stars, last pushed 2mo ago), licensed MIT. It adds 126 tokens to every session and 3,354 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
form-optimization
Reduce abandonment in every form, signup, and checkout flow. Multi-step logic, field reduction, inline validation, and completion micro-copy. Use when building signup flows, checkout pages, or any multi-field input.
product-configurator-design
Designing build-your-own product configurators (Tesla-style, custom-pricing, plan-builders) with constraint logic, real-time pricing, validation, and save-and-share mechanics. Honest about infinite-options (decision paralysis), canned-bundles-only (no real customization), and guided-configuration (smart defaults plus…
amazon-storefront-design
Amazon Store builder — page layouts, brand story, shoppable images, traffic driving, conversion optimization.
pm-brand-motion
A guided process for defining a brand's motion style and making a logo animation demonstration.
pm-proto
A product-prototyping workflow for planning how an application should work and what its screens should contain. It connects product requirements to interface layouts and interactions.
pm-business-model
A Chinese-language workflow for designing a business model, including customers, value, channels, relationships, and revenue.