Conciseness

The body is dense with non-obvious, Paddle-specific facts ("Paddle returns `403` for both permission and authentication problems", "PATCH /prices/{price_id} replaces `allowances` in full", "aggregation defaults to `sum`, the only option during early access") rather than concepts Claude already knows; directives are terse ("Don't call Paddle in the middle of the customer's request") and nearly every sentence carries API-specific information the model cannot infer. The rare transitional sentences ("Read this first. These facts change how you build the integration.") are single-line signposts, not padding, so it sits at the 'lean and efficient' anchor rather than the 'minor over-explanation' anchor below it.

Actionability

Every step ships complete, copy-paste-ready TypeScript: the `paddleApi` helper with error/Retry-After handling, `check-usage-billing-access.ts` with an explicit AUTH_ERRORS branch, `setup-usage-billing.ts` with real request bodies, a `sendUsageEvent` worker with a quantity regex (`/^(0|[1-9]\d{0,34})(\.\d{1,9})?$/`) and enumerated retry/failure outcomes, the webhook handler, plus the exact run command (`node --env-file=.env.local --import tsx scripts/<name>.ts`). Specific error codes (`usage_event_timestamp_too_old`, `meter_action_usage_balance_unit_duplicate`, `subscription_prorated_billing_not_allowed_for_allowance`) and concrete SQL make the common cases fully executable — matching the top anchor, not the 'minor gaps' anchor at 4.

Workflow Clarity

Seven numbered steps are strictly ordered with an explicit gate up front (Step 2 "If the account isn't in early access... stop there"), validation checkpoints inside the flow (Step 4 confirms "`remaining.total` should equal the allowance `amount` multiplied by the item quantity" with a failure-troubleshooting list), feedback loops for batch financial operations (outbox retry with backoff, "Stop the run on a `429`", and a 7-item "Verify the integration" checklist including idempotency: "Send the same row again... Confirm `remaining.total` doesn't change"). This exceeds the 'clear sequence with explicit validation steps; feedback loops; checklists' anchor.

Progressive Disclosure

There are no bundle files at all (no `references/`, `scripts/`, `assets/`), so all ~500 lines — including API-constraint lists, the renewals/plan-changes table, and the pitfalls section — are inlined in SKILL.md. Internal structure is good (numbered steps, clear headers, well-signaled external doc links), but content that would naturally live in a one-level-deep reference file (e.g. the meter/price constraint catalog or the renewal semantics table) is inline, and the under-50-lines exception for header-only skills clearly doesn't apply. This matches 'some structure but content that should be separate is inline' better than the 'most content appropriately placed' anchor at 4, which presumes a working split across files.

Specificity

The description enumerates the full set of concrete sub-tasks — "early access check, usage balance units, meters, price allowances, usage events, balance gating, and `usage_balance.depleted`" — plus the implementation constraint "using the Paddle API directly", in third person. This matches 'lists multiple specific concrete actions; comprehensive coverage' rather than the anchor 4 example, which would leave visible gaps in the workflow's coverage.

Completeness

The 'what' is explicit and comprehensive, and the 'when' is stated through the fully specified scenario ("Add Paddle usage-based billing (early access) to a Next.js app"), which functions as equivalent explicit trigger guidance rather than a merely implied one — so it is not capped at 3. It is not 5 because there is no dedicated trigger clause ('Use when...' / 'when the user mentions...') naming the user-facing moments to fire, e.g. 'Use when the user wants prepaid or metered usage on Paddle subscriptions'.

Trigger Term Quality

Strong natural domain phrases are present ("usage-based billing", "Paddle", "Next.js", "meters", "usage events", "price allowances", "balance"), which a user asking for this integration would plausibly say. It falls short of the top anchor because common synonyms are missing: "metered billing", "pay-as-you-go", "prepaid usage", "credits", and "overage" — the vocabulary the body itself surfaces in 'When to use this skill' ("10,000 API calls, 1 million tokens") is absent from the description.

Distinctiveness Conflict Risk

The niche is tightly bounded by three distinct markers — Paddle, usage-based billing (early access), and the `usage_balance.depleted` webhook — so it would essentially never fire for a non-Paddle or non-metered billing request, and even sibling Paddle skills (catalog-setup, checkout-web) are differentiated by the 'usage-based billing' qualifier. This matches 'clear niche with distinct triggers; minimal conflict risk'.