Review the seams of revenue-critical journeys — the points where a request crosses from client to server, from your system to a payment processor, or from a webhook back into your system — so a journey that looks correct in any one tier does not break where the tiers meet. The dominant seam failures are non-idempotent money-moving requests, client-enforced rules the server never re-validates, webhook consumers that assume exactly-once/in-order delivery, unbounded retries that become retry storms, and PCI DSS SAQ-scope misjudgment.
\nUse this skill when the user asks to:
\nDo not use this skill for:
\nrepo evidence, context7-grounded, documentation-based, or inference.Processor idempotency semantics, webhook retry windows, event ordering, and signature verification are version-sensitive. The bundled official sources are the versioned ground truth for this skill: every processor-specific claim must trace to them and is labeled documentation-based, and the ledger records the version and last-verified date so a claim can be re-checked. This static-review skill's own tool grant is read-only (Read Grep Glob); when the invoking harness additionally provides Context7 or official-documentation tools, use them to confirm the current behavior against the bundled snapshot (resolve-library-id then query-docs, labeled context7-grounded) and to cover a processor the bundle does not. For a processor with no bundled or fetched coverage, say so and treat the claim as inference — never rely on memorized API details.
Follow the step-by-step review and output contract in workflow and output. At a high level: (1) map the seams in scope; (2) for each money-moving/account-creating request, check idempotency against reachable retry/replay; (3) check server re-validation of every client-enforced rule; (4) check webhook consumers for idempotency + order-tolerance; (5) check retry safety; (6) if requested, form the advisory SAQ-scope opinion; (7) emit findings with evidence tiers and tier-internal handoffs.
\nLabel each finding repo evidence (seen in the code), context7-grounded (current provider docs via Context7), documentation-based (official docs), or inference. Documentation never proves a specific deployment's live behavior — say so.
Static review only. Never transmit, request, store, or reproduce cardholder data (PAN/CVV), API keys, session tokens, or webhook signing secrets; treat any such string as a redact-and-flag finding. Never execute payment flows or contact any live/sandbox/staging payment system. PCI SAQ-scope output is an advisory opinion, never an attestation.
\nEscalate to incident response on any evidence of a live failure (duplicate charges in logs, replayed webhooks, retry amplification). Escalate SAQ-scope opinions to the merchant's compliance owner or a QSA as advisory input.
\nLoad these only when needed:
\nReturn, at minimum:
\n