Conciseness

The body is lean and every sentence carries non-obvious API/domain facts (plan/apply model, one-active-plan limit, amount_micros, start_date requirements for approved subscriptions, per-store pricing quirks). It assumes Claude's competence — no space is spent explaining what App Store Connect or pricing are — matching the 5 anchor; the 4 anchor would require identifiable over-explanation that could be trimmed, and none is present.

Actionability

Guidance is fully executable: exact tool names (`get-product-store-state`, `create-product-store-state-plan`), precise field paths (`store_state.base_plans[<id>].other_regions_config.usd_price`), concrete review/progress URLs, CLI commands (`rc products show <product-id> --store-state`), and specific limits (name ≤ 30 characters, description ≤ 45). The 5 anchor's copy-paste-ready, common-case coverage is met.

Workflow Clarity

The six-step write flow is clearly sequenced with explicit validation checkpoints: inspect first, poll plan to a terminal status, a hard user-confirmation gate before apply, never apply past item-level blockers ("re-plan until there are no item-level blockers"), poll apply to `applied`/`apply_errored`, and error-recovery feedback loops (retry re-runs only unapplied items; start a new plan if the store changed). This matches the 5 anchor including feedback loops for a destructive/batch operation, so no cap applies.

Progressive Disclosure

No bundle files exist, so the skill is a single well-organized file with clear sections (Reads, Prerequisites, Confirm before applying, write flow, Gotchas, CLI equivalents) and appropriately deferred details ("Refer to the MCP tool schemas (or `rc commands --schemas --json`) for exact parameters"). It misses the 5 anchor because at ~85 lines the dense per-store pricing rules (App Store, Play, RC Billing) are inlined where a reference file could carry them; the simple-skill 5 exception applies only under 50 lines.

Specificity

The description names concrete actions ("inspect or change the state of products") and comprehensively enumerates the affected state ("prices, availability, localizations, review screenshots") across four named stores. It falls just short of the 5 anchor because the action verbs are limited to inspect/change rather than multiple distinct concrete actions; it is clearly above the 3 anchor, which expects only 1-2 actions without comprehensive coverage.

Completeness

It explicitly answers both questions: what ("inspect or change the state of products ... prices, availability, localizations, review screenshots ... via RevenueCat product-store-state plans") and when ("Use when the user wants to inspect or change..."). This matches the 5 anchor with concrete trigger phrases; it cannot score lower since the 'when' clause is explicit and the 'what' is concrete.

Trigger Term Quality

Natural terms a RevenueCat user would say are well covered: "App Store Connect", "Google Play Console", "prices", "availability", "localizations", "review screenshots". A few plausible natural phrasings are missing (e.g. "offer", "trial", "update pricing", "make products available"), which places it at the 4 anchor rather than the 5 anchor's comprehensive synonym coverage, but well above the 3 anchor's missing common variations.

Distinctiveness Conflict Risk

The phrase "via RevenueCat product-store-state plans" carves out a clear niche, but "inspect or change the state of products in App Store Connect, Google Play Console" could plausibly trigger for users wanting to manage store products directly without RevenueCat — a minor overlap risk with the closely related revenuecat-cli skill, matching the 4 anchor rather than the 5 anchor's minimal conflict risk.