Conciseness

The body is lean and assumes Claude's competence — no explanation of what usage-based billing is or how APIs work; every line carries Metronome-specific facts (endpoints, limits, units, deprecations) such as "POST /v1/ingest with a bare JSON array of 1 to 100 event objects… not wrapped in an object". Nothing reads as padding.

Actionability

Fully concrete guidance throughout: exact endpoints ("POST /v2/contracts/edit", "POST /v1/credits/migrateToContracts"), field-level specifics ("a unique transaction_id… re-sent unchanged on every retry", "usage_filter (group_key and group_values)"), hard limits ("250 line items per Stripe invoice", "24 hours after billing_period_end_date by default"), and "Always send USD amounts in cents (1000 is 10.00 USD)" — the common cases are covered with specifics an instruction-only skill can deliver without code.

Workflow Clarity

The routing sequence is clear with explicit pre-write checkpoints — "Read the linked page before answering any integration question", "confirm which environment that token targets… and get the user's explicit confirmation before any write", and separate confirmation for Stripe writes. However, post-write verification and error-recovery feedback loops are delegated to the linked skills rather than present here, so the 'explicit validation steps; feedback loops' of the 5 anchor is only partially met in-file; this is clearly above the 3 anchor, where checkpoints would be missing or implicit.

Progressive Disclosure

The body is a pure overview that delegates all detail one level deep via well-signaled links: a routing table matching each task to its doc page, a workflows table linking each operational skill, and a closing "Key documentation" section for unmatched requests, with a fallback rule ("use the documentation index… append .md to the page URL"). No nested references, no inlined detail that belongs elsewhere.

Specificity

Lists multiple concrete capability areas with specific sub-topics in parentheses — "event ingestion (single and batch, idempotency, billable metrics)", "contract design (rate cards, overrides, dimensional pricing, products)", "invoicing lifecycle (grace periods, finalization, Stripe sync)", "credit and commit management (prepaid, postpaid, thresholds, auto-recharge)" — giving comprehensive coverage of the Metronome domain rather than the minor gaps of the 4 anchor.

Completeness

Explicitly answers both: what ("Guides Metronome usage-based billing integration decisions" followed by five enumerated capability areas) and when ("Use when building, modifying, or reviewing any Metronome integration — including…" with concrete trigger scenarios). The 'when' clause is explicit and specific, matching the 5 anchor rather than the 4 anchor's 'could be more explicit'.

Trigger Term Quality

Covers the natural phrases a user would actually say — "ingesting usage events", "creating customers, contracts, or rate cards", "managing credits and commits", "syncing invoices with Stripe Billing", "billing AI applications for token usage", "self-serve (PLG) pricing", "migrating from Stripe Billing Meters to Metronome" — including synonyms and both vendor names. Not the 4 anchor's 'a few natural terms missing'.

Distinctiveness Conflict Risk

"Metronome" is named in nearly every clause, and the triggers span a clear niche (usage-based billing integration, Stripe sync, Stripe Billing Meters migration) with distinct triggers and minimal overlap risk with other skills.