Conciseness

Mostly efficient directive prose, but time-sensitive version data sits in the main body rather than a deprecated/old-patterns section ('Latest Stripe API version: 2026-08-26.dahlia' plus a 7-row SDK version table), and a few passages explain rationale Claude doesn't need (the payment_method_types rule spends several clauses justifying dynamic payment methods and conversion). This fits 'Mostly efficient but includes some unnecessary explanation or could be tightened'.

Actionability

Highly concrete throughout: 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', 'automatic_tax: { enabled: true }'), and named deprecated patterns. It falls just short of fully copy-paste ready because the StripeClient rule says what not to do ('Do not use the deprecated global/module-level API key pattern') without showing the correct instantiation example.

Workflow Clarity

The routing table gives a clear decision flow, 'Read the relevant reference file before answering any integration question or writing code' sets the sequence, and the tax rule includes an explicit pre-flight checkpoint ('read the tax reference and confirm the user has an active registration') with the failure consequence. It matches 'Clear sequence with most checkpoints present; minor validation gaps' — there is no explicit error-recovery/feedback loop, but no destructive or batch operation requires one.

Progressive Disclosure

The body is a lean overview that routes each domain to a real one-level-deep bundle file via the integration routing table (payments, connect, billing, tax, treasury, security — all verified present in references/), with a mandatory 'read the relevant reference' directive and no nested references inside the bundle. This matches 'Clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation'.

Specificity

The description enumerates many concrete, named capabilities — 'API selection (Checkout Sessions vs PaymentIntents)', 'Accounts v2, controller properties', 'automatic_tax, product tax codes', 'Treasury financial accounts', 'API key management, API key permissions, webhooks, OAuth' — giving comprehensive, non-abstract coverage of the skill's scope. It clearly matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage'; nothing is generic filler.

Completeness

Both questions are answered explicitly: 'Guides Stripe integration decisions across...' states what the skill does, and 'Use when planning, building, modifying, testing, or reviewing any Stripe integration, including...' gives concrete, multiple trigger phrases. This matches the anchor for 'Clearly and explicitly answers both what AND when with concrete trigger phrases'.

Trigger Term Quality

The 'Use when' clause covers many natural phrasings — 'accepting payments', 'building marketplaces', 'setting up subscriptions', 'collecting sales tax, VAT, or GST', 'creating connected accounts', 'implementing secure key handling' — plus synonyms. A few common natural terms users would say are still missing (e.g. invoices, refunds, disputes, webhooks as a trigger), placing it between the 4 anchor ('good keyword coverage; a few natural terms missing') and 5.

Distinctiveness Conflict Risk

The description is tightly scoped to the Stripe domain with distinct, Stripe-specific triggers (Checkout Sessions, Connect, Stripe Tax, Treasury, connected accounts), so it is unlikely to fire for unrelated skills. It matches 'Clear niche with distinct triggers; minimal conflict risk'.