Conciseness

Mostly efficient: the `prorationBillingMode` decision tables, status constraints, error codes, and `onPaymentFailure` semantics are Paddle-specific knowledge Claude cannot reliably be assumed to know, so those tokens earn their place. But ~50 lines of generic Supabase client boilerplate (the skill itself concedes "if your project already has equivalent helpers, use those instead") and notable duplication between the main sections and "Common pitfalls" (the mixed-interval rule appears at both "Same-billing-interval rule" and "Mixed billing intervals on items"; credit-not-refund appears in both the flow table and pitfalls) push it past the level-4 anchor. It is not level 2 because the majority of the body is dense, non-obvious domain content rather than padding.

Actionability

The body delivers a complete, copy-paste-ready Server Action ("use server", imports, auth check, ownership check via the email bridge, trialing-aware `prorationBillingMode`, `revalidatePath`, a slim DTO, and an `ApiError`-to-message map), an executable `previewUpdate` snippet, and an `onPaymentFailure: 'apply_change'` variant — concrete code with exact API values throughout. It stops short of level 5 because `getPaddleInstance` is imported from "@/utils/paddle/get-paddle-instance" and a `PricingTier` constant is invoked in verification step 8, yet neither is shown anywhere in the skill — minor gaps an implementer must fill from elsewhere. It is well above level 3: nothing shown is pseudocode or hand-waving.

Workflow Clarity

The workflow is clearly sequenced with explicit validation checkpoints: prerequisites and env vars, decision tables for proration mode and subscription status, "Preview before committing" as an explicit pre-commit checkpoint ("Don't try to compute the prorated amount yourself — the preview is the source of truth"), numbered steps 1–6 inside the action with auth rejected "before any DB query or SDK call", error-recovery feedback loops (declined payment → retry message; renewal lock → try again after renewal; rate limit → back off), and a 9-step "Verify the integration" checklist covering declining test cards, trialing subscriptions, invalid price IDs, and forged/anonymous access. This matches the level-5 anchor (clear sequence, explicit validation, feedback loops, checklist).

Progressive Disclosure

Section organization is good (clean headers, tables, and a clearly labeled one-level-deep "Related docs" list of external Paddle links), but this is a 333-line single-file skill with no references/scripts/assets bundle at all. Content that clearly belongs in a separate file is inlined — most notably the Supabase client helpers, which the text says are shared with `subscription-cancel` and match the Paddle starter kit, and therefore would be duplicated across sibling skills. That fits the level-3 anchor (some structure, content that should be separate is inline); it is not level 2 because structure and navigation within the file are strong, and not level 4 because at this length, with shared boilerplate inlined, the organization gaps exceed "minor".

Specificity

The description lists six concrete, named actions for a clearly identified domain: "auth, ownership check, `prorationBillingMode`, items-array replace semantics, preview-before-commit, and `on_payment_failure` handling" on top of "Change a Paddle subscription's plan from a Next.js Server Action". This is comprehensive coverage of the capability surface, matching the level-5 anchor (multiple specific concrete actions) rather than level 4 (minor gaps) or level 3 (only 1-2 actions). Voice is third person, so no specificity penalty applies.

Completeness

The "what" is clear and concrete (change a Paddle subscription's plan from a Next.js Server Action, with the enumerated sub-capabilities), but there is no "Use when..." clause or equivalent explicit trigger guidance — the "when" is only weakly implied by naming the stack. Per the judging guidelines, a missing explicit trigger clause caps completeness at 3; it is not 4 because the when-condition is never stated, and not 2 because the what is specific rather than vague.

Trigger Term Quality

Good keyword coverage: "Change a Paddle subscription's plan", "Next.js Server Action", plus searchable API terms (`prorationBillingMode`, `on_payment_failure`) that a developer stuck on this exact problem would use. A few natural terms are missing — "upgrade", "downgrade", "switch tier", "billing" — which the body itself names as the user-facing flows, so it stops short of the level-5 comprehensive-coverage anchor but sits above level 3 (missing common variations).

Distinctiveness Conflict Risk

"Change a Paddle subscription's plan from a Next.js Server Action" carves out a clear niche: a specific vendor (Paddle), a specific framework mechanism (Next.js Server Action), and a specific operation (plan change on an existing subscription). Trigger overlap with other skills is minimal — at most the sibling subscription-sync/cancel skills it distinguishes itself from — matching the level-5 anchor (clear niche with distinct triggers).