Conciseness

The body is lean and task-specific — no concept explanations Claude already knows, and dense operational detail ("roborev review --branch --wait --type design [--panel <name>|none]", "The `--wait` flag blocks until the review completes"). Minor trimmable redundancy keeps it below anchor 5: the bullets after the command snippets re-explain --base/--panel already shown in the snippets, the Examples section restates steps 2–4, and the "These instructions are guidelines, not a rigid script" boilerplate adds little.

Actionability

Commands are copy-paste ready and complete, including the heredoc + `git rev-parse --verify --end-of-options` validation snippet, exact flag semantics (--panel fans out, --panel none forces single-agent), and concrete recovery suggestions ("roborev status", "roborev init"). This matches anchor 5: fully executable guidance with specific examples covering both the default and --base cases.

Workflow Clarity

The four-step sequence (validate inputs → build and run → present results → offer next steps) has an explicit validation checkpoint ("git rev-parse ... || exit 1", "If validation fails ... Do not proceed") and error-recovery feedback loops (report errors, suggest roborev status/init/re-run), matching anchor 5. The destructive/batch cap does not apply — this is a read-only review, and the panel-synthesis rule ("offer fix on that parent id — never an individual reviewer") adds a further correctness checkpoint.

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), and all sections are well-organized with clear headers, so navigation is easy — but the file runs ~135 lines with no external references, and detail like the Panels subsection and Sandbox access section is inline where a split (or trimming) would serve the token budget. This fits anchor 4 ('good structure; most content appropriately placed; minor organization gaps') rather than anchor 5, which presumes appropriately split content and one-level-deep references.

Specificity

The description "Use only when the user explicitly invokes $roborev-design-review-branch" states no capability actions at all — nothing like 'request a design review of all commits on the branch and present the verdict and findings' appears. It only edges above anchor 1 because the token itself names the domain (design review, branch); it does not list even one concrete action, so anchor 3 ('names domain and 1-2 concrete actions') is out of reach.

Completeness

Only the 'when' half is present, and it is maximally explicit ("Use only when the user explicitly invokes..."), but the 'what' — what the skill actually does (run a design review of the branch and present results) — is entirely absent. This matches anchor 2 ('only when is present without what') and falls short of anchor 3, which requires a clear 'what'.

Trigger Term Quality

Relevant keywords exist but only inside the literal token and the phrase "explicitly invokes" — e.g. "design review", "branch", "roborev". Natural trigger phrases a user would say ("review this branch's design", "design review of my commits") are deliberately omitted, which fits anchor 3 ('some relevant keywords but missing common variations or synonyms'); it is not anchor 4 because no prose-level natural terms are given, and not anchor 2 because the token does carry the key terms.

Distinctiveness Conflict Risk

The explicit-invocation-only trigger ("Use only when the user explicitly invokes $roborev-design-review-branch") makes accidental triggering essentially impossible — a clear niche with distinct triggers and minimal conflict risk, exactly anchor 5, and clearly better than anchor 4's 'minor overlap risk'.