Conciseness

The ~36-line body explains only what Claude doesn't already know (the deeplink scheme, the prerequisite "OnlySwitch must be installed and allowed to handle the onlyswitch:// URL scheme", the one-deeplink-per-request rule) and moves the 40-row id table out of the body. No filler or concept explanations; matches anchor 5 ("every token earns its place").

Actionability

The command `open "onlyswitch://run?type=builtIn&id=<id>"` is fully executable, reinforced with a copy-paste-ready concrete example (`id=16384` for empty trash) and a real reference table (references/switch-ids.md) mapping user phrases to ids with alias columns. Matches anchor 5 (copy-paste ready, specific examples cover the common cases).

Workflow Clarity

The sequence (resolve intent to id -> open the deeplink -> confirm to the user) is clear and the no-match fallback is stated, but there is no validation checkpoint before firing destructive switches — the skill's flagship examples include "empty trash", "clear clipboard", "eject discs", and Xcode derived data cleanup, which are irreversible. The rubric's judging guideline caps destructive/batch workflows without validation at 3, taking precedence over the simple-skill exception; the "Confirm" step only reports after the fact rather than validating before execution, so this is anchor 3 (steps present but checkpoints missing), not 4.

Progressive Disclosure

The body is a clear overview with a well-signaled, verified, one-level-deep reference ([references/switch-ids.md](references/switch-ids.md)), and the bulky id table is appropriately split into that file rather than inlined; switch-ids.md itself references no further files. Matches anchor 5 (clear overview, well-signaled one-level-deep references, easy navigation).

Specificity

"Resolve the request to the correct switch id and open the onlyswitch deeplink" plus "Invoke OnlySwitch built-in switches or buttons via deeplink" list multiple concrete actions, and the enumeration ("empty trash, keep awake, dark mode, mute, hide desktop, clear clipboard, eject discs, Xcode derived data, and any other built-in switch or button") gives comprehensive coverage of the domain. This matches the anchor-5 example's comprehensiveness; anchor 4 would require a coverage gap, and none exists given the explicit catch-all.

Completeness

The 'what' is explicit ("Invoke OnlySwitch built-in switches or buttons via deeplink... open the onlyswitch deeplink") and the 'when' is an explicit "Use when the user asks to toggle or trigger an OnlySwitch action (e.g. empty trash, keep awake, ...)" with concrete trigger phrases. This mirrors the anchor-5 exemplar structure; anchor 4's weaker/implicit 'when' does not apply.

Trigger Term Quality

Natural user phrases like "empty trash", "keep awake", "dark mode", "mute", "hide desktop", "clear clipboard", "eject discs" are exactly what a user would say, and synonym pairs ("toggle or trigger", "switches or buttons") add variation. Anchor 4 would require missing natural terms; the "e.g." framing plus "any other built-in switch or button" makes the coverage comprehensive for this domain (no file extensions exist here to include).

Distinctiveness Conflict Risk

The niche is clear (OnlySwitch, a specific macOS app, with the trigger scoped to "an OnlySwitch action"), but the example phrases "mute", "empty trash", "dark mode", "hide desktop" are generic system actions that could also match other macOS-automation or system-control skills if the user has no OnlySwitch intent. This fits anchor 4 ("minor overlap risk with closely related skills") better than anchor 5, since anchor 5 demands minimal conflict risk from distinct triggers.