Conciseness

The body is lean and imperative with no explanation of concepts Claude already knows, but it embeds time-sensitive version data — 'Latest Stripe API version: 2026-08-26.dahlia' and the seven-row SDK version table — outside any deprecated/old-patterns section, which the guidelines say should penalize conciseness. It fits anchor 4 (efficient with minor instances that could be trimmed) rather than 5, and is well above 3 since everything else earns its place.

Actionability

Guidance is largely executable: exact commands ('npm i -g @stripe/cli', 'stripe sandbox create', 'stripe whoami --format json'), exact parameter names ('payment_method_types', 'allowed_payment_method_types', 'integration_identifier'), and a routing table mapping each integration type to a specific API and reference file. It falls short of anchor 5 because the most common integration flows (e.g., creating a Checkout Session with the mandated client-instance pattern) have no code example — they are deferred to references — and a few lines ('If stripe sandbox create is used, don't use MCP') are cryptic without surrounding context.

Workflow Clarity

The core sequence is discernible — identify what you're building via the routing table, 'Read the relevant reference file before answering any integration question or writing code', then apply the critical rules — and the automatic_tax rule plus the 'stripe sandbox claim' check act as validation checkpoints. It sits at anchor 4 rather than 5 because the workflow is implied by scattered directives rather than stated as a sequence, and there is no error-recovery/feedback loop; it is not a 3 since checkpoints like the tax registration confirmation are explicit.

Progressive Disclosure

The SKILL.md body is a clear overview that splits content appropriately: a routing table signals all six real, one-level-deep reference files (payments, connect, billing, tax, treasury, security — all verified to exist, none nesting further .md references), plus a 'Key documentation' section for cross-cutting cases. This matches the anchor-5 pattern of a concise overview with well-signaled one-level-deep references and easy navigation.

Specificity

The description lists many concrete capabilities with named APIs and parameters — 'Checkout Sessions vs PaymentIntents', 'Accounts v2, controller properties', 'automatic_tax, product tax codes', 'separate sandboxes vs the shared test mode sandbox' — giving comprehensive coverage of the skill's scope. It exceeds the anchor-4 'minor gaps' level because every capability listed is a concrete, named action or decision domain, and it is in third person ('Guides…').

Completeness

Both halves are explicit: a detailed 'what' (environment planning, API selection, Connect setup, billing, tax, Treasury, migrations, security) and a concrete 'when' ('Use when planning, building, modifying, testing, or reviewing any Stripe integration, including…'). This matches the anchor-5 example structure of what-list followed by an explicit 'Use when… including…' trigger clause; the 'when' is neither missing nor only implied.

Trigger Term Quality

The 'Use when' clause covers natural phrases users would actually say — 'accepting payments', 'building marketplaces', 'setting up subscriptions', 'collecting sales tax, VAT, or GST', 'creating connected accounts', 'implementing secure key handling' — including synonyms (accepting/processing payments, sales tax/VAT/GST). Coverage is comprehensive with explicit synonyms, matching the anchor-5 example's pattern; nothing common is missing.

Distinctiveness Conflict Risk

The skill occupies a clear niche — Stripe integrations specifically — with distinct triggers (Stripe-named domains like Connect accounts, Stripe Tax, Treasury) that no generic payments or file-handling skill would claim. Conflict risk with similar skills is minimal, matching the anchor-5 'clear niche with distinct triggers'.