Conciseness

Mostly efficient — no padding explaining concepts Claude already knows — but the full heredoc command block is repeated verbatim in §2 and §3, and the Examples section restates the numbered steps nearly word-for-word. This matches anchor 3 ('mostly efficient but could be tightened'): it is not 2 because there is no unnecessary conceptual explanation, and not 4 because the duplicated blocks are a clear trim candidate (§3 could reference 'the command from step 2').

Actionability

Fully copy-paste-ready commands: the heredoc + 'git rev-parse --verify --end-of-options "$commit^{commit}" || exit 1' validation snippet, 'roborev review "$commit" --wait --type design [--panel <name>|none]', concrete error-recovery suggestions ('roborev status', 'roborev init'), and the exact job-id extraction source ('Enqueued job <id> for ...' line). Both common cases (commit omitted vs specified, panel vs none) are covered with specific handling, matching anchor 5.

Workflow Clarity

Five clearly sequenced steps (validate inputs → build command → background run → present results → offer next steps) with an explicit validation gate ('If validation fails, inform the user the ref is invalid. Do not proceed.') and error-recovery guidance for daemon/repo failures in step 4. The operation is non-destructive so the destructive-cap does not apply, and the validation + recovery structure matches the anchor 5 example.

Progressive Disclosure

No bundle files exist and the single SKILL.md is well-sectioned (Usage, Instructions with numbered subsections, Examples, Panels, See also) with no nested references and easy navigation — appropriate for a single-purpose workflow skill. It is not 5 because at ~157 lines the body carries duplicated command blocks and a fairly detailed Panels subsection plus an Examples section that together push past a lean overview, creating minor organization gaps rather than a cleanly minimal core.

Specificity

The description 'Use only when the user explicitly invokes /roborev-design-review' names the design-review domain only via the command token and states no concrete actions or capabilities whatsoever. It sits between anchor 1 (pure abstraction like 'Helps with documents') and anchor 2 ('Names the domain but actions are minimal or generic') — the domain is identifiable, but there is no action statement at all, so it cannot reach 3, which requires 1-2 named concrete actions.

Completeness

Only the 'when' is present, and it is explicit ('Use only when the user explicitly invokes /roborev-design-review'), while the 'what' — that the skill runs a roborev design review of a commit and presents verdict and findings — is entirely missing from the description. This is exactly anchor 2 ('only when is present without what', e.g. 'Use when working with documents'); it cannot be 3 because a clear 'what' is required, and cannot be 1 because the 'when' is fully explicit.

Trigger Term Quality

The only trigger term is the literal '/roborev-design-review'; natural phrases a user would say when needing this skill — 'design review', 'review this commit', 'roborev' — are absent. This matches anchor 3 ('some relevant keywords but missing common variations or synonyms'): there is a relevant keyword, but coverage of natural language variants is missing.

Distinctiveness Conflict Risk

Gating on the literal command makes accidental triggering for the wrong skill very unlikely — a clear, distinct trigger. It does not reach 5 because sibling skills named in the body ('/roborev-review --type design', '/roborev-design-review-branch', '/roborev-fix') occupy adjacent command space and the description itself does not articulate the niche, leaving minor overlap risk.