Conciseness

Every line carries Metronome-specific knowledge Claude cannot know — 'POST /v1/ingest with a bare JSON array of 1 to 100 event objects', '24 hours after billing_period_end_date by default', '1000 is 10.00 USD', '250 line items per Stripe invoice' — with zero space spent explaining concepts Claude already knows. Not 4: not even minor trimming opportunities exist; the routing tables and rule list are pure high-signal content.

Actionability

Guidance is fully concrete: exact endpoints ('POST /v2/contracts/edit', 'POST /v1/credits/migrateToContracts'), field names ('transaction_id', 'usage_filter', 'rollover_fraction', 'spend_threshold_configuration'), a routing table mapping each task to a specific API and doc page, and exact request-body shape ('not wrapped in an object'). Per the rubric's instruction-skill note, the absence of code is not penalized; the guidance is specific enough to execute directly, and gaps are closed by mandated doc reads.

Workflow Clarity

There is a clear routing sequence (match the task in the table → read the linked page/skill in full → confirm environment and get explicit user confirmation before any write) with real checkpoints for risky operations, including separate confirmation for Stripe writes ('identify the Stripe account and mode behind the Stripe key'). Not 5: the multi-step sequences for the actual tasks (migration, setup, contract creation) are delegated to linked external skills rather than sequenced inline, so validation feedback loops within this body are confirmation gates rather than full validate-fix-retry loops.

Progressive Disclosure

The body is a clear overview with well-signaled, one-level-deep references: a routing table of doc pages per task, a workflows table of external skills, and a fallback ('use the documentation index... append .md to the page URL to fetch it as Markdown'). Not 4: navigation is fully organized with no buried references and no inline content that belongs in a separate file — the critical-rules list is appropriately kept in the main file as the always-loaded core.

Specificity

The description lists many concrete capabilities — 'event ingestion (single and batch, idempotency, billable metrics)', 'rate cards, overrides, dimensional pricing', 'grace periods, finalization, Stripe sync', 'prepaid, postpaid, thresholds, auto-recharge', 'arrears invoicing, tax providers, line item limits' — with comprehensive coverage of the Metronome domain. Not 4: no identifiable coverage gaps; each named item is a specific capability, not generic filler.

Completeness

Both questions are answered explicitly: the opening 'Guides Metronome usage-based billing integration decisions' followed by an enumerated capability list states the what, and 'Use when building, modifying, or reviewing any Metronome integration — including...' provides an explicit when with concrete trigger phrases. Not 4: the 'when' is not merely present but itemized with a dozen specific scenarios, matching the anchor-5 example pattern.

Trigger Term Quality

The 'Use when' clause covers the natural phrases users would actually say: 'ingesting usage events', 'creating customers, contracts, or rate cards', 'syncing invoices with Stripe Billing', 'billing AI applications for token usage', 'self-serve (PLG) pricing', 'commit burn', 'migrating from Stripe Billing Meters to Metronome', plus synonyms (usage-based billing, PLG). Not 4: no common variation of a Metronome-related request is missing from the trigger list.

Distinctiveness Conflict Risk

'Metronome' is a distinctive product name repeated in nearly every trigger, carving out a clear niche with minimal overlap risk; even the Stripe-related triggers are scoped by 'with Stripe Billing' and 'from Stripe Billing Meters to Metronome'. Not 4: it would not plausibly capture requests intended for other skills because every trigger is anchored to Metronome or an explicit Metronome migration path.