Conciseness

The body is largely lean and restricted to Stripe-specific facts Claude cannot know (latest API version, sandbox vs test-mode rules, exact parameter names), but two things could be trimmed or would rot: the conversion rationale 'dynamically display the most relevant eligible payment methods to each customer to maximize conversion', and time-sensitive version data ('2026-09-30.endive', the 7-row SDK version table) that is not placed in a deprecated/old-patterns section. Not 3, because there is no explanation of concepts Claude already knows and nearly every line is an imperative rule.

Actionability

Fully executable guidance throughout: copy-paste commands ('npm i -g @stripe/cli', 'stripe sandbox create', 'stripe whoami --format json'), exact parameter rules ('Never include payment_method_types… use allowed_payment_method_types'), named deprecated patterns ('stripe.api_key = …', 'Stripe.setApiKey'), and a routing table mapping every common scenario to a specific API and reference file. Not 4, because no common case is left without concrete instruction.

Workflow Clarity

The sequence is clear — classify the task via the routing table, then 'Read the relevant reference file before answering any integration question or writing code', then apply the critical rules — and pre-flight checkpoints are present ('confirm the user has an active registration', 'first make sure stripe sandbox claim is run'). Not 5, because the body presents rules as a list rather than an ordered workflow with explicit validate/fix/retry feedback loops (verification detail is deferred to the reference files); not 3, because ordering and preconditions are explicit and stated.

Progressive Disclosure

A true overview that keeps only defaults, a routing table, and critical rules in SKILL.md, pushing domain detail to six real, well-signaled, one-level-deep reference files (references/payments.md, connect.md, billing.md, tax.md, treasury.md, security.md — all present in the bundle, none nesting further pointers). The 'Building… | Recommended API | Details' table makes navigation unambiguous; not 4, since there are no organization gaps to point to.

Specificity

Enumerates concrete, named capabilities — 'API selection (Checkout Sessions vs PaymentIntents)', 'Connect platform setup (Accounts v2, controller properties)', 'product tax codes', 'webhooks, OAuth' — covering the full Stripe surface with no vague padding. Matches the 'multiple specific concrete actions; comprehensive coverage' anchor and exceeds the 4 anchor, which requires coverage gaps.

Completeness

Explicitly answers both what ('Guides Stripe integration decisions across development and test environment planning… Treasury financial accounts… security best practices') and when ('Use when planning, building, modifying, testing, or reviewing any Stripe integration') with concrete trigger phrases — the exact pattern of the 5 anchor. Not 4, because the 'when' clause is already fully explicit and specific.

Trigger Term Quality

The 'Use when' clause covers the natural phrases users actually say, with synonyms: 'accepting payments', 'processing payments', 'setting up subscriptions', 'collecting sales tax, VAT, or GST', 'building marketplaces', 'creating connected accounts', 'implementing secure key handling'. Comprehensive keyword coverage; nothing common is missing.

Distinctiveness Conflict Risk

Clear niche with Stripe-specific triggers (Checkout Sessions, PaymentIntents, Accounts v2, automatic_tax, connected accounts) that no other skill domain would match. Minimal conflict risk; not 4, since even closely related skills (e.g. a generic payments skill) are distinguished by the Stripe-only terminology.