CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/payment-flow-test-author

Build-an-X workflow that authors the full payment-flow test suite in three phases: the refund matrix (full / partial / multiple-partials / over-refund / already-refunded, per-gateway APIs for Stripe, Adyen, PayPal, Braintree), the chargeback / dispute suite (Visa + Mastercard reason codes, evidence submission windows, won / lost / accepted dispositions), and webhook replay + recovery via gateway-native simulators (Stripe CLI trigger / resend, Adyen Customer Area resend, PayPal Webhook Simulator, Braintree sampleNotification). Driven by the state model in payment-flow-states-reference. Use when building refund, dispute, or payment-webhook-robustness coverage for a payment integration; for generic (non-payment) webhook receiver testing use webhook-delivery-tester in the qa-notifications plugin.

72

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Medium

Suggest reviewing before use

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, token-efficient workflow body that sequences three payment-test phases with concrete code and offloads depth to three real, clearly-signaled reference files. The main gaps are undefined test helpers in examples and the absence of explicit error-recovery feedback loops.

Suggestions

Define or sketch the reused test helpers (createSucceededIntent, triggerLostDispute, waitForChargebackEvent, postWebhook, signPayload) so the code examples are fully copy-paste ready.

Add an explicit validate-then-fix feedback loop after the coverage-matrix emission step (e.g., run the suite, triage failures, backfill missing cells).

Make the 'Emit the coverage matrix' step an explicit verification checkpoint with a pass/fail criterion rather than only a reporting instruction.

DimensionReasoningScore

Conciseness

Lean and dense with domain-specific gotchas (raw-body signatures, async-vs-sync assertions, idempotency double-refund); avoids explaining concepts Claude already knows and every section earns its tokens.

5 / 5

Actionability

Real SDK calls and bash commands (stripe.refunds.create, generateTestHeaderString, stripe trigger/resend) with concrete expected states, but several test helpers (createSucceededIntent, triggerLostDispute, waitForChargebackEvent) are undefined, leaving minor gaps.

4 / 5

Workflow Clarity

Phase 0→3 sequence is clearly ordered with explicit assertion checkpoints and a final coverage-matrix checklist, but there are no explicit error-recovery feedback loops for the batch test-generation process.

4 / 5

Progressive Disclosure

Clear overview body with three well-signaled, one-level-deep references (reason-codes.md, replay-simulators.md, advanced-recovery-scenarios.md), each announced with its contents; all referenced files exist and do not nest further.

5 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, highly specific description that concretely names the three phases, four gateways, and key variants, with an explicit 'Use when' trigger and an explicit boundary against a neighboring skill. Its only weakness is mild jargon ('payment-webhook-robustness') in the trigger phrasing.

DimensionReasoningScore

Specificity

Lists multiple concrete actions across three phases (refund matrix, chargeback/dispute suite, webhook replay+recovery) with per-gateway APIs and specific variants, giving comprehensive coverage.

5 / 5

Completeness

Explicitly answers 'what' (authors the three-phase payment-flow test suite) and 'when' via a concrete 'Use when building refund, dispute, or payment-webhook-robustness coverage' trigger clause.

5 / 5

Trigger Term Quality

Strong natural keywords ('refund', 'dispute', 'chargeback', 'payment integration', 'webhook') but 'payment-webhook-robustness' is slightly unnatural jargon and a few common synonyms are absent.

4 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (payment-flow test authoring) and explicitly redirects generic webhook-receiver testing to webhook-delivery-tester, minimizing conflict risk.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents