CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

upgrade-stripe

Guide for upgrading Stripe API versions, webhook endpoints, server-side SDKs, Stripe.js, and mobile SDKs

64

1.08x
Quality

74%

Does it follow best practices?

Impact

100%

1.08x

1 of 3 eval scenarios. Add 2 more for a full score.

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./providers/codex/plugin/skills/upgrade-stripe/SKILL.md

The canonical home for this skill is upgrade-stripe in stripe/ai

SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is a strong, largely executable upgrade runbook: it front-loads target-version selection with verification and staleness rules, provides copy-paste code for the common config cases, and closes with a genuinely rigorous checklist including testing, cutover, and rollback. Its main weaknesses are moderate redundancy and tutorial padding (webhook event semantics explained twice, conceptual 'Types of Changes' material) and inlining of the webhook-destination migration details that would be cleaner as a reference file.

Suggestions

Explain the thin-vs-snapshot event distinction once (either in the webhook checklist step or in Important Notes, not both) and trim the conceptual 'Types of Changes' / 'Best Practice' sections to the facts Claude cannot infer.

Give concrete commands for the strongly-typed SDK upgrade path (e.g., the Maven/Gradle/go get/nuget command for selecting an SDK release targeting the chosen API version) to match the executable quality of the dynamic-language examples.

Extract the v2 snapshot-event destination migration procedure from checklist step 6 into a references/ file, keeping the checklist step as a one-line pointer.

DimensionReasoningScore

Conciseness

Mostly efficient and dense with Stripe-specific facts Claude cannot reliably know (thin vs. snapshot events, monthly release cadence, 72-hour rollback), but there is unnecessary material that could be tightened: the snapshot-vs-thin webhook distinction is explained twice (in 'Choose a target API version' and again in 'Important Notes'), the 'Types of Changes' and 'Best Practice' sections are tutorial-flavored, and 'Understanding Stripe API Versioning' re-states concepts. The bundled fallback version '2026-09-30.endive' is time-sensitive but is explicitly framed as a snapshot with staleness guidance, so it is justified rather than penalized.

3 / 5

Actionability

Mostly executable guidance: copy-paste-ready code for Python/Ruby/Node global config and per-request overrides, a curl example with the 'Stripe-Version' header, npm/script-tag updates, and precise webhook-destination replacement instructions (inspect snapshot_api_version, create replacement, dual secrets during cutover, disable old destination). Minor gaps keep it below anchor 5: strongly-typed SDK upgrades are directed abstractly ('update the SDK to target a new API version') without a concrete package-manager command, and the checklist's 'update mobile SDK versions' lacks examples.

4 / 5

Workflow Clarity

The 9-step Upgrade Checklist is clearly sequenced with explicit validation checkpoints — test with the 'Stripe-Version' header before committing (step 5), create and test replacement destinations with dual signing secrets during cutover (step 6) — plus explicit error-recovery feedback: the 72-hour Workbench rollback and the instruction to disable/delete the old destination to avoid duplicate delivery. This matches anchor 5 (clear sequence, explicit validation, feedback loops, checklist for a complex process) rather than anchor 4, whose final step is a single unadorned 'verify' line.

5 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), so the skill is scored on its own structure: well-organized sections, each detail topic (SDK versioning, Stripe.js, mobile) explicitly pointed at the authoritative docs.stripe.com page, and the fallback version clearly quarantined with staleness conditions. Good structure with minor organization gaps keeps it at anchor 4 rather than 5: the ~190-line body inlines content that could live in reference files — notably the dense webhook/v2-destination migration procedure buried inside checklist step 6 — and the under-50-line exception for a 5 does not apply.

4 / 5

Total

16

/

20

Passed

Description

61%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 concise, domain-specific, and names the four upgrade surfaces clearly, but it is a bare capability list: one generic action verb, no 'when to use' trigger clause, and no synonyms for common user phrasings. It is serviceable but below the good-example standard, which pairs a concrete 'what' with an explicit 'use when' clause.

Suggestions

Add an explicit trigger clause, e.g., 'Use when the user asks to upgrade or migrate a Stripe API version, update Stripe SDKs (server-side, Stripe.js, or mobile), or retire a pinned webhook/API version.'

Include natural synonyms and variations users would say — 'update', 'migrate', 'apiVersion', 'pin', 'deprecated Stripe API' — to strengthen trigger matching.

Consider stating the concrete actions performed, not just the objects touched (e.g., 'compare pinned versions against the target, update client config and Stripe-Version overrides, migrate webhook destinations'), which would raise specificity from one generic verb to several concrete actions.

DimensionReasoningScore

Specificity

The description names the domain ('upgrading Stripe API versions') and enumerates concrete targets ('webhook endpoints, server-side SDKs, Stripe.js, and mobile SDKs'), but the action itself is a single generic verb — 'Guide for upgrading' — with no distinct concrete actions. This matches anchor 3 ('names domain and 1-2 concrete actions, but not comprehensive') better than anchor 4, which requires several specific actions; the enumerated objects add specificity but not additional actions.

3 / 5

Completeness

The 'what' is clear (a guide for upgrading Stripe API versions, webhook endpoints, and SDKs), but there is no 'Use when...' clause or equivalent explicit trigger guidance — no 'when should Claude use it' at all. Per the judging guidelines, a missing 'Use when...' clause caps completeness at 3, which this clearly is; it is above anchor 2 because the 'what' is concrete, not vague.

3 / 5

Trigger Term Quality

Good natural keyword coverage: 'upgrading Stripe API versions', 'webhook endpoints', 'server-side SDKs', 'Stripe.js', 'mobile SDKs' are phrases users would naturally say when needing this skill. It falls short of anchor 5's comprehensive coverage because common synonyms and variations are missing — e.g., 'update', 'migrate', 'apiVersion', 'deprecated API', or file/package terms like 'stripe npm'.

4 / 5

Distinctiveness Conflict Risk

The Stripe versioning niche is distinct and unlikely to trigger for unrelated skills ('Stripe', 'API versions', 'Stripe.js' are strong discriminators). It sits below anchor 5 only because, without explicit 'use when' triggers, it has minor overlap risk with closely related skills such as generic Stripe integration, webhook configuration, or SDK dependency-update skills.

4 / 5

Total

14

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

stripe/ai

Path

providers/codex/plugin/skills/upgrade-stripe/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.