Conciseness

The body is mostly efficient procedural instruction with no re-teaching of concepts Claude already knows, but it could be tightened: Step 4a's two public-preview items (lines 266–267) repeat nearly identical four-part disclosure requirements, Step 3's guardrails include a ~200-word single-sentence paragraph (line 228), and the progress-checklist block is repeated verbatim four times. This matches anchor 3 ("Mostly efficient but includes some unnecessary explanation or could be tightened"); not 2 because the bulk of the text earns its place as executable instruction.

Actionability

The guidance is copy-paste ready throughout for an instruction-only skill: exact question scripts and numbered options ("'Use it as a starting point' — prefill all decisions from the prior plan"), verbatim warning copy to output (the margin warning text with pricing link), concrete Grep patterns ("`transfers.create`, `payouts.create`", "`account.updated`, `capability`, `payout`"), and specific field names and tool names. Matches anchor 5 — specific examples cover the common cases.

Workflow Clarity

Steps 0–6 are clearly sequenced with explicit validation checkpoints and feedback loops: compatibility validation is "MANDATORY before presenting recommendation", fee-economics validation "ALWAYS runs, even on auto-filled values", BLOCKED combinations trigger a fix and explicit "re-run the recommendation with the corrected configuration" loop, and the "Does this recommendation look right?" checkpoint offers a change-and-retry path. Matches anchor 5 (clear sequence, explicit validation, feedback loops, checklists).

Progressive Disclosure

Eight real, one-level-deep reference files, each clearly signaled at its point of use with its purpose stated ("Read <references/decision-matrix.md> and apply it to the user's answers"), and the SKILL.md body serves as the workflow overview. Anchor 4 rather than 5 because Step 4a inlines dense compatibility rules that overlap <references/compatibility-matrix.md>, and Step 3's long guardrail paragraph (line 228) duplicates material that belongs in <references/discovery-questions.md>.

Specificity

The description names the Stripe Connect domain in rich, concrete terms ("charge patterns", "Dashboard access", "split payments, revenue sharing, multi-party payments") but never states what the skill actually does — the word "recommendation" appears only obliquely ("provides a company URL or business description for a recommendation"). This matches anchor 2 ("Names the domain but actions are minimal or generic"): not 3 because no concrete skill action is stated, and not 1 because the language is specific rather than vague.

Completeness

The 'when' is explicit and thorough ("Use this skill when the user asks about Stripe Connect configuration... or asks about payment flows"), but the 'what' is never stated — the skill's function (recommending a Connect integration configuration) is absent from the description itself. This matches anchor 2 ("only 'when' is present without 'what'"); it cannot score 3 or above because a clear 'what' is a prerequisite for those anchors.

Trigger Term Quality

Comprehensive natural-language trigger coverage with synonyms and variations: "marketplace, platform, multi-vendor store, gig platform, or subscription platform", "pay out sellers, vendors, or providers", "onboarding or KYC", "white-label payments, or embedded payments", "POS, booking, invoicing". This clearly matches the anchor-5 example of comprehensive natural terms including synonyms.

Distinctiveness Conflict Risk

The description occupies a clear Stripe Connect niche with distinct triggers ("connected account Dashboard or responsibility configurations", "charge patterns", " KYC for merchants, sellers, and vendors") that are unlikely to fire for unrelated skills. Minimal conflict risk — anchor 5.