Conciseness

Mostly efficient tables and imperative rules, but the SDK version table (Ruby 20.0.0 … .NET 53.0.0) and pinned API version "2026-09-30.endive" are time-sensitive version data presented outside any old-patterns/deprecated section, which the rubric explicitly penalizes. The sandbox/MCP rules ("If `stripe sandbox create` is used, don't use MCP") also fragment one flow with slight redundancy.

Actionability

Concrete, executable commands (`npm i -g @stripe/cli`, `stripe sandbox create`, `stripe sandbox claim`, `stripe whoami --format json`) and exact parameter guidance (`payment_method_types: ['card_present']`, `allowed_payment_method_types`, `integration_identifier`) with a decisive routing table. Falls short of 5 because no copy-paste-ready code examples cover the common creation flows; exceeds 3 since guidance is concrete rather than pseudocode.

Workflow Clarity

The routing table plus "Read the relevant reference file before answering any integration question or writing code" gives an unambiguous decision flow, and the automatic_tax rule embeds an explicit checkpoint ("read the tax reference and confirm the user has an active registration"). Not 5 because the sandbox/CLI/MCP setup steps are scattered across separate paragraphs rather than clearly sequenced.

Progressive Disclosure

Appropriately split overview: the body stays lean and points to six one-level-deep reference files, all of which exist in references/ (payments, connect, billing, tax, treasury, security), each mapped by task in the routing table. Minor gap: the table uses non-clickable angle-bracket paths (`<references/payments.md>`) inconsistently with the real markdown link `[tax reference](references/tax.md)`, so navigation signaling is not fully uniform.

Specificity

Enumerates many concrete decision domains with specific API names — "Checkout Sessions vs PaymentIntents", "Accounts v2, controller properties", "automatic_tax, product tax codes", "Treasury financial accounts" — with comprehensive coverage and no notable gaps. Not 4 because the 4 anchor requires "minor gaps in coverage," which this description does not have.

Completeness

Explicitly answers both questions: the what ("Guides Stripe integration decisions across development and test environment planning, API selection, Connect platform setup, …") and the when ("Use when planning, building, modifying, testing, or reviewing any Stripe integration, including …") with concrete trigger phrases — the exact pattern of the 5 anchor. Also correctly third person.

Trigger Term Quality

The when-clause covers natural user phrasings with synonyms: "accepting payments", "building marketplaces", "setting up subscriptions", "collecting sales tax, VAT, or GST", "creating connected accounts", "implementing secure key handling". This matches the 5 anchor's comprehensive synonym coverage (e.g., sales tax/VAT/GST), well above the 4 anchor's "a few natural terms missing".

Distinctiveness Conflict Risk

Everything is anchored to "any Stripe integration," giving a clear niche and minimal conflict with unrelated skills. However, several trigger phrases — "accepting payments", "setting up subscriptions", "collecting sales tax, VAT, or GST" — are not Stripe-specific on their own, creating minor overlap risk with closely related payments/tax skills, which fits the 4 anchor better than 5's "minimal conflict risk".