CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/payment-webhook-replay

Workflow-driven skill that builds payment webhook replay + recovery tests. Covers the idempotency contract (every webhook handler must handle redelivery without side effects), the replay simulators (Stripe CLI `stripe trigger`, Adyen Customer Area resend, PayPal Webhook Simulator, Braintree webhook test), the signature-verification gauntlet (HMAC-SHA256 per gateway, expired-timestamps rejection), and the partial-failure recovery scenarios. Use when designing webhook robustness tests.

75

Quality

94%

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

85%

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

The body is highly actionable with executable code, a clear sequenced workflow, and clean one-level-deep progressive disclosure. Its one weakness is conciseness: the Overview and some surrounding prose explain concepts Claude already knows.

Suggestions

Tighten the Overview: drop the 'source of truth for asynchronous state transitions' editorializing and lead directly with the four properties the suite tests.

Trim prose that restates the obvious around code blocks (e.g., 'Redelivery must not double-process' before the idempotency test) — the test name and assertions already convey it.

Consider folding the Limitations section into the existing gateway tables where it duplicates per-gateway signature/replay notes, to reduce token overhead.

DimensionReasoningScore

Conciseness

The body is mostly dense and actionable (code blocks, comparison tables, anti-patterns), but the Overview editorializes concepts Claude knows ('source of truth for asynchronous state transitions') and some prose restates the obvious ('Redelivery must not double-process'); it is efficient but could be tightened, so it does not reach the 'every token earns its place' level of 3.

2 / 3

Actionability

Fully executable TypeScript using the stripe SDK and fetch with jest/vitest-style assertions, real CLI commands ('stripe trigger payment_intent.succeeded', 'stripe events resend evt_test_12345'), and specific per-gateway tables — copy-paste ready, matching the top anchor.

3 / 3

Workflow Clarity

The 'How to use' section is a clearly sequenced 5-step build with an explicit end-to-end validation checkpoint ('run the Worked example end to end against staging') and in-process assertions; as test authoring rather than destructive/batch work, the validation-cap does not apply, keeping it above the implicit-checkpoint level of 2.

3 / 3

Progressive Disclosure

Core material lives inline while advanced scenarios are split into a single clearly-signaled, one-level-deep reference (references/advanced-recovery-scenarios.md, verified self-contained with no chained references), matching the 'clear overview with well-signaled one-level-deep references' anchor.

3 / 3

Total

11

/

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.

The description is specific, complete, and distinctive, with an explicit 'Use when' trigger and concrete capability coverage; it uses third-person voice throughout. Its only minor weakness is density of technical jargon, though that describes capabilities rather than trigger terms.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'builds payment webhook replay + recovery tests', the idempotency contract, replay simulators, the signature-verification gauntlet, and partial-failure recovery — matching the 'multiple specific concrete actions' anchor rather than the partial coverage of a 2.

3 / 3

Completeness

Explicitly answers both what ('builds payment webhook replay + recovery tests' plus the four coverage areas) and when ('Use when designing webhook robustness tests'), satisfying the explicit-trigger requirement that would otherwise cap completeness at 2.

3 / 3

Trigger Term Quality

Natural user-facing terms are present ('payment webhook replay', 'recovery tests', 'webhook robustness tests') with an explicit trigger ('Use when designing webhook robustness tests'); the technical jargon describes capabilities, not triggers, so it stays above the 'missing common variations' level of 2.

3 / 3

Distinctiveness Conflict Risk

The payment-webhook-replay niche with gateway-specific triggers is clearly distinguishable and unlikely to fire for unrelated skills, matching the 'clear niche with distinct triggers' anchor.

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