Conciseness

The body is dense and directive with no padding about what Stripe is or how payments work — e.g. 'API key default: Always Recommend a restricted API key (RAK) (`rk_` prefix) over a secret key'. It falls short of the level-5 'every token earns its place' bar because of inline time-sensitive version data ('Latest Stripe API version: **2026-09-30.endive**' and the 7-row SDK version table), which the rubric flags unless placed in a deprecated/versions section, and the marketing-flavored rationale 'which enables you to configure payment method settings from the Dashboard and dynamically display the most relevant eligible payment methods to each customer to maximize conversion'. It is clearly above level 3, which expects unnecessary explanations.

Actionability

Concrete, executable guidance is present: copy-paste commands ('npm i -g @stripe/cli', 'stripe sandbox create', 'stripe whoami --format json'), exact parameters ('payment_method_types: [\'card_present\']', 'automatic_tax: { enabled: true }', 'integration_identifier'), and exact deprecated patterns to avoid ('stripe.api_key = …', 'Stripe.setApiKey'). It sits at level 4 rather than 5 because the most common integration tasks (e.g., creating a Checkout Session or subscription) have no inline example — they are fully delegated to reference files — whereas the level-5 anchor expects inline examples covering the common cases. It is well above level 3, since what is inline is executable, not pseudocode.

Workflow Clarity

The sequence is clear: route the task via the integration table, 'Read the relevant reference file before answering any integration question or writing code', apply the Critical rules, and fall back to the Key documentation links when no single domain fits. There is an explicit pre-flight checkpoint ('Before enabling automatic_tax ... read the tax reference and confirm the user has an active registration'). No destructive or batch operations exist, so no validation cap applies; it is below level 5 only because there are no feedback/error-recovery loops (e.g., what to do when a required feature isn't supported in a sandbox).

Progressive Disclosure

The body is a concise overview with a routing table that maps each task to a real one-level-deep reference file (<references/payments.md>, connect.md, billing.md, tax.md, treasury.md, security.md — all six exist in references/), and none of the reference files nest further references (verified by grep). This matches the level-5 anchor: clear overview, well-signaled references, appropriate split, easy navigation.

Specificity

The description names concrete, specific capabilities across the full Stripe surface: 'development and test environment planning (separate sandboxes vs the shared test mode sandbox)', 'API selection (Checkout Sessions vs PaymentIntents)', 'Connect platform setup (Accounts v2, controller properties)', 'tax and registrations (Stripe Tax, automatic_tax, product tax codes)', 'Treasury financial accounts', 'migrating from deprecated Stripe APIs', and 'security best practices (API key management... webhooks, OAuth)'. This matches the level-5 anchor (multiple specific concrete actions, comprehensive coverage); it exceeds level 4, which only expects 'several specific actions; minor gaps'.

Completeness

It explicitly answers both questions: 'what' is a detailed list of guidance domains, and 'when' is an explicit 'Use when planning, building, modifying, testing, or reviewing any Stripe integration, including...' clause with concrete trigger phrases. This is exactly the level-5 anchor pattern (cf. the PDF example: capabilities sentence + 'Use when working with... or when the user mentions...'). It is above level 4 because the 'when' clause is explicit and specific, not merely present.

Trigger Term Quality

The 'Use when' clause includes natural phrases users would actually say: 'accepting payments', 'building marketplaces', 'processing payments', 'setting up subscriptions', 'collecting sales tax, VAT, or GST', 'creating connected accounts', 'implementing secure key handling', plus action verbs 'planning, building, modifying, testing, or reviewing'. Synonym coverage (sales tax/VAT/GST; payments/checkout) matches the level-5 anchor; level 4 ('a few natural terms missing') understates the synonym breadth present.

Distinctiveness Conflict Risk

The description is scoped tightly to Stripe ('Guides Stripe integration decisions', 'any Stripe integration') with Stripe-specific artifacts (Checkout Sessions, PaymentIntents, Accounts v2, Stripe Tax, sandboxes) forming a clear niche with minimal conflict risk against generic payment or document skills. It matches the level-5 anchor; level 4 ('minor overlap risk with closely related skills') would apply only if a sibling Stripe-adjacent skill existed, but nothing here is generic enough to cross-trigger.