Conciseness

Most content is genuinely non-obvious domain knowledge (error codes like "subscription_locked_renewal" and "subscription_trialing_items_update_invalid_options", the credit-not-refund rule, mixed-interval constraints), but the trialing→`do_not_bill` rule is restated in at least four places (proration table, flow table, status table, pitfalls) and ~45 lines of standard Supabase client boilerplate Claude already knows are inlined. Fits anchor 3 — mostly efficient but could be tightened — rather than 2 because the padding is limited to specific spots, and rather than 4 because the duplication and boilerplate exceed 'minor instances'.

Actionability

The full Server Action is near copy-paste ready (auth, ownership check, ApiError mapping, revalidatePath, slim DTO) with complete Supabase helpers, an executable preview snippet, an apply_change override example, and a 9-step verification checklist. One minor gap keeps it from anchor 5: `getPaddleInstance` is imported but never defined anywhere in the skill, so the code is not fully self-contained.

Workflow Clarity

Clear sequence — choose `prorationBillingMode` → check subscription status → preview before commit → run the update — with explicit validation checkpoints: preview numbers rendered on a confirm screen, auth/ownership checks before any SDK call, and a "Verify the integration" checklist with expected outcomes (e.g. a declined card keeps the old plan under `prevent_change`). Error-recovery feedback (retry after renewal lock, back off on 429, update payment method) is present. Matches anchor 5.

Progressive Disclosure

Well-organized single file with clear section headers and a related-docs list; the core domain tables (proration modes, status rules) are appropriately inline for immediate use. Minor gaps: the shared Supabase helper boilerplate and the Paddle error-code catalog would fit better in a references/ file (they're shared with the paired subscription-cancel skill), and no bundle files exist at all. Fits anchor 4 rather than 3 because structure and navigation are good, and rather than 5 because ~330 lines of reference-worthy material is inlined with no one-level-deep reference split.

Specificity

The description lists multiple concrete actions — "auth, ownership check, `prorationBillingMode`, items-array replace semantics, preview-before-commit, and `on_payment_failure` handling" — alongside the core action "Change a Paddle subscription's plan from a Next.js Server Action". Coverage is comprehensive for this skill's scope, matching anchor 5 rather than 4 because no meaningful capability is left out.

Completeness

The "what" is explicit and concrete, but there is no "Use when..." clause or equivalent explicit trigger guidance — the "when" is only weakly implied by the opening action phrase. Per the rubric's cap, a missing 'Use when...' clause caps completeness at 3; it fits anchor 3 rather than 4 because the when is implied, not stated.

Trigger Term Quality

"Change a Paddle subscription's plan" is a natural user phrase, and API terms like "prorationBillingMode" and "on_payment_failure" match what a developer integrating Paddle would say or search. However, common natural synonyms such as "upgrade," "downgrade," or "switch tier" are absent, fitting anchor 4 (good coverage, a few natural terms missing) rather than 5.

Distinctiveness Conflict Risk

The phrases "Paddle subscription's plan" and "Next.js Server Action" carve a clear niche with distinct triggers, and the plan-change flow is distinct from adjacent skills (cancel, sync). Minimal conflict risk — matches anchor 5.