stripe-subscription-billing-test-author • testland • Registry • Tessl

testland/stripe-subscription-billing-test-author

Builds test suites for Stripe recurring-billing flows: trial-to-paid conversion, proration on plan upgrade and downgrade, dunning on failed renewal, cancel and reactivation, and the full subscription webhook event matrix (invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted, invoice.paid). Uses Stripe Billing test clocks (POST /v1/test_helpers/test_clocks) to time-travel through billing cycles without calendar delay. Distinct from stripe-test-cards-and-webhooks (one-time PaymentIntents) and payment-flow-test-author (idempotency + replay robustness). Does not cover single-event CLI replay or handler idempotency testing (see payment-flow-test-author for those). Use when authoring tests for subscription or recurring-billing integrations.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

75%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 strong, dense single-file walkthrough: five end-to-end scenarios with executable-ish code, explicit polling validation, a valuable anti-patterns checklist, and honest limitations. Weaknesses are minor: undefined helper functions, a slightly padded Overview and repeated citation phrasing, and a monolithic structure that inlines reference-grade tables instead of splitting them out.

Suggestions

Define the helper functions used in the code samples (toEpoch, waitForClockReady, getLatestInvoice) once, or inline their short implementations, so the examples are fully copy-paste executable.

Trim the Overview's re-explanation of subscription billing basics and consolidate the repeated 'Per docs.stripe.com/...' preambles into the final References section to save context tokens.

Move the webhook event matrix and CI integration YAML into references/ files (e.g., references/webhook-event-matrix.md) linked from short SKILL.md sections, so the main file stays an overview.

Dimension	Reasoning	Score
Conciseness	The bulk is non-obvious, Stripe-test-specific gotchas (poll clock until 'ready', 'canceled' is terminal, same proration_date for preview and update, retry-cycle testing), but minor over-explanation could be trimmed: the Overview re-explains subscription billing basics, and the 'Per docs.stripe.com/...' citation preamble repeats ~12 times. Not 5 because of that padding; not 3 since most tokens carry information Claude cannot be assumed to already know.	4 / 5
Actionability	Near-executable TypeScript for every scenario plus concrete bash/YAML for CLI and CI, but helper functions (toEpoch, waitForClockReady, getLatestInvoice) and constants (PRICE_ID, NEW_PRICE_ID) are referenced without definitions, so code is not fully copy-paste ready. Matches the 'mostly executable with minor gaps' anchor.	4 / 5
Workflow Clarity	Steps 1-6 are clearly sequenced with an explicit validation checkpoint ('Poll until clock.status === ready before asserting', reinforced in the anti-patterns table) and a dunning-recovery path. Not 5 because there is no error-recovery feedback loop (e.g., what to do when an advance fails or the clock errors), which the top anchor expects.	4 / 5
Progressive Disclosure	Well-organized sections with clear headers, a clearly signaled References section, and no nested or buried references. Not 5 because the 345-line single file has no bundle split at all: the 9-row webhook event matrix and CI YAML are reference-shaped content inlined in SKILL.md rather than one-level-deep reference files.	4 / 5
	Total	16 / 20 Passed

Description

100%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.

The description is a model example: concrete scenario enumeration, the key mechanism (test clocks), explicit when-to-use guidance in third person, and explicit disambiguation from sibling skills with stated exclusions. Every dimension lands cleanly on the top anchor with no over-claims or padding.

Dimension	Reasoning	Score
Specificity	Enumerates concrete actions comprehensively: 'trial-to-paid conversion, proration on plan upgrade and downgrade, dunning on failed renewal, cancel and reactivation, and the full subscription webhook event matrix (invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted, invoice.paid)' plus the concrete test-clock mechanism (POST /v1/test_helpers/test_clocks). No coverage gaps, so above the 'several specific actions; minor gaps' anchor.	5 / 5
Completeness	Explicitly answers both: 'what' via the enumerated scenario list and test-clock mechanism, and 'when' via the literal closing clause 'Use when authoring tests for subscription or recurring-billing integrations.' with concrete trigger phrases.	5 / 5
Trigger Term Quality	Natural user phrasing is comprehensively covered: 'Stripe recurring-billing', 'subscription', 'proration', 'dunning', 'trial', 'webhook event matrix', 'test clocks', 'cancel and reactivation'. Common variations (renewal, failed payment, billing cycle) are all present, matching the synonym-inclusive top anchor.	5 / 5
Distinctiveness Conflict Risk	Explicitly draws boundaries against siblings: 'Distinct from stripe-test-cards-and-webhooks (one-time PaymentIntents) and payment-flow-test-author (idempotency + replay robustness)' and states exclusions ('Does not cover single-event CLI replay or handler idempotency testing'). Clear niche, minimal conflict risk.	5 / 5
	Total	20 / 20 Passed

Validation

100%

Warnings & errors only

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

2 days ago

Table of Contents

Discovery Implementation Validation