| name | revenue-critical-journey-integrity-review |
| description | Use this skill to review the cross-tier seams of revenue-critical journeys — checkout, payment submission, account creation, and login — for idempotency of money-moving and account-creating requests, server-side re-validation of client-enforced rules, webhook duplicate/out-of-order handling, retry-storm safeguards, and PCI DSS SAQ-scope judgment. Use when a request crosses client-to-server, system-to-processor, or webhook-back-into-system and a failure at that seam would double-charge, double-fulfill, bypass a required step, drop revenue, or misjudge PCI scope. Static review only; it does not execute payment flows and its PCI SAQ output is an advisory scoping opinion, never a compliance attestation. |
| allowed-tools | Read Grep Glob |
| metadata | {"author":"github: Raishin","version":"0.1.0","updated":"2026-07-16","category":"resilience","lifecycle":"experimental"} |
Revenue-Critical Journey Integrity Review
Purpose
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.
When to use
Use this skill when the user asks to:
- review whether a checkout, payment, subscription, coupon, or account-creation request is safe to retry (idempotency at money-moving seams),
- confirm the server re-validates rules the client enforces (price, discount, quantity, eligibility, step-completion),
- review a webhook consumer for duplicate-delivery and out-of-order handling,
- review retry/backoff/circuit-breaker safety at a revenue-critical seam across web, mobile, or backend consumers,
- get an advisory PCI DSS SAQ-scope opinion for the payment integration model actually in the code.
When not to use
Do not use this skill for:
- tier-internal review that an owning specialist owns — DOM XSS/CSP and client injection (use the frontend security review), backend authorization-model design, mobile-platform specifics, or infrastructure hardening. This skill reviews the seam, not the interior; hand tier-internal findings to the owning agent.
- issuing a PCI compliance attestation, signing an SAQ, or acting as an assessment of record. SAQ-scope output here is advisory only.
- any live exercise of a payment system — executing flows, replaying webhooks, or sending requests to live/sandbox/staging processors. This skill is static review only.
Preconditions
- The money-moving and account-creating request paths in scope, across whichever tiers exist.
- The webhook consumer code and the event types it acts on.
- The retry configuration (max attempts, backoff, jitter, timeout, circuit breaker) for the seams in scope.
- The payment integration model (redirect, iframe/hosted fields, direct post/custom form) if a SAQ-scope opinion is requested.
- The processor/SDK and version in scope, so idempotency and webhook guidance matches the real API surface.
Lean operating rules
- Confirm retry/replay reachability before flagging an idempotency gap; a genuinely non-retryable internal call is not a finding.
- Treat the server as the only enforcement boundary; a client-only check is UX, not enforcement.
- Require webhook consumers to be both idempotent (dedupe by event id or business key) and order-tolerant.
- Require bounded, backoff-with-jitter retries with a timeout at every revenue seam; add a circuit breaker or dead-letter path for backend/queue consumers.
- Give a PCI SAQ-scope opinion only against the integration model present in the code, name the candidate SAQ, and label it advisory.
- Never request, echo, store, or reproduce cardholder data, API keys, session tokens, or webhook signing secrets; redact-and-flag any that appear.
- Label every claim
repo evidence, context7-grounded, documentation-based, or inference.
Context7 documentation protocol
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.
Workflow
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.
Decision gates
- Block only on a seam failure with a demonstrated reachable retry/replay/bypass path.
- Every processor-specific claim is Context7-grounded or documentation-based, never memory.
- Every SAQ-scope statement is advisory and tied to the integration model in the code.
- Every tier-internal finding is handed off, not adjudicated.
Evidence classification
Label 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.
Security and privacy constraints
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.
Escalation conditions
Escalate 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.
References
Load these only when needed:
Response minimum
Return, at minimum:
- the seam(s) in scope and, per finding, the failure class and evidence tier;
- the cross-tier failure narrative (how a retry, replay, or bypass reaches a wrong outcome);
- concrete remediation and an exact verification step;
- the advisory SAQ-scope opinion when requested, labeled advisory;
- tier-internal handoffs and any incident-response escalation.
Anti-goals
- Do not expand into tier-internal review; own the seam, hand off the interior.
- Do not present a SAQ-scope opinion as a compliance determination.
- Do not exercise any live payment system or reproduce any secret or PAN.
- Do not assert processor behavior from memory.
