CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/payment-flow-states-reference

Pure-reference catalog of payment lifecycle state machines across Stripe, Adyen, PayPal, and Braintree: canonical states (created / requires_action / processing / succeeded / requires_capture / canceled / failed), authorisation vs capture, asynchronous webhook states, and refund / dispute / chargeback transitions. Use when designing tests for payment flows or auditing state-handling code; this is the state model, not a builder - to author suites on it use refund-test-matrix-builder (refunds), chargeback-flow-test-author (disputes), or payment-webhook-replay (webhook replay).

80

Quality

100%

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

100%

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

A well-structured reference skill: concise, concrete, with a clear sequenced workflow and proper one-level-deep progressive disclosure into a real bundle file. It avoids teaching concepts Claude already knows and stays focused on provider-specific state-machine detail.

DimensionReasoningScore

Conciseness

Lean throughout — it assumes Claude's competence and adds only payment-domain specifics (state names, test cards, webhook sequences) rather than explaining what payments or state machines are; tables and worked examples each earn their tokens.

3 / 3

Actionability

Instruction-only yet highly actionable: concrete test cards (Stripe `4000 0027 6000 3184`, Adyen `4917 6100 0000 0000`), exact state transitions to assert, and specific webhook events to wait on — per the rubric's scoring note, absence of code is not penalized when guidance is this concrete.

3 / 3

Workflow Clarity

The 'How to use' section gives a clearly sequenced 5-step process (identify → map → enumerate transitions → derive cases → assert coverage) with the final step acting as a verification checkpoint, and the anti-patterns table doubles as a checklist; no destructive/batch validate-fix-retry gap applies.

3 / 3

Progressive Disclosure

SKILL.md is an overview that repeatedly and clearly signals one-level-deep references to references/payment-state-machines.md (a real file containing the per-platform grids and state machines), keeping the detail out of the main file; companion and consumer skills are listed for navigation.

3 / 3

Total

12

/

12

Passed

Description

100%

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 precise, third-person description that cleanly states what the skill is, when to use it, and how it differs from adjacent builder skills. It names concrete capabilities and providers without fluff.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities: 'canonical states (created / requires_action / processing / succeeded / requires_capture / canceled / failed), authorisation vs capture, asynchronous webhook states, and refund / dispute / chargeback transitions' across four named providers — far beyond a single action.

3 / 3

Completeness

Explicitly answers both what ('Pure-reference catalog of payment lifecycle state machines...') and when ('Use when designing tests for payment flows or auditing state-handling code') with an explicit 'Use when' clause.

3 / 3

Trigger Term Quality

Includes natural terms a user would say — 'designing tests for payment flows', 'auditing state-handling code', 'payment flows' — with good domain coverage rather than generic jargon.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (state model reference) and explicitly disambiguates from sibling builders — 'this is the state model, not a builder - to author suites on it use refund-test-matrix-builder... chargeback-flow-test-author... payment-webhook-replay' — making wrong-skill triggering unlikely.

3 / 3

Total

12

/

12

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