Conciseness

The body is lean and imperative throughout — 'Never spend judgement on what that gate decides: run it first and read its findings', 'Never report the with-arm score alone' — with no explanation of concepts Claude already knows; the only background given (what the deterministic gate covers, what an eval run stages) is repo-specific knowledge Claude would not have. It is not 4 because no section can be trimmed without losing a directive or a concrete failure example.

Actionability

Guidance is concrete and executable: exact files to read ('task.md, criteria.json, inputs/setup.sh'), exact commands ('gh pr diff <number>', 'bin/evalctl check --changes origin/main', 'bin/evalctl grade --suite <dir> --judge-cmd ...'), and an exact output shape ('[{"name", "score", "max", "note"}]'). Each judgement question includes concrete failure instances ('a clean working tree when the task asks for an untracked artifact'), meeting anchor 5 for an instruction-only skill with copy-paste-ready commands covering the common cases.

Workflow Clarity

Multi-step processes are explicitly sequenced: scoping options by input type, 'Then ask, in this order' for the six scenario questions, a numbered 4-step grading procedure, and ranked reporting. Validation checkpoints are present — the adapter 'rejects a judgement that does not cover exactly the pending criteria' with a --resume recovery loop, and 'still read a sample of the evidence' guards the totals. Not 4 because both the sequence and the validation/recovery loops are explicit, not implicit.

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), and none are needed: the body is a compact ~100-line judgement guide split into seven clearly headed sections with no buried references and no content that belongs in a separate file. Navigation is trivial via the section headers; nothing is inlined that should be split out, so it matches the well-organized, self-contained top anchor rather than anchor 4's 'minor organization gaps'.

Specificity

The description enumerates multiple concrete judgement actions — 'whether a scenario discriminates, whether a rubric is fair to the unit it tests, whether a recording shim is faithful, and whether a skill's description and body guide an agent' plus 'grades the criteria an eval run left pending' — which comprehensively covers the skill's capabilities. It sits at anchor 5 rather than 4 because the enumerated checks map onto the full set of non-gate judgements the skill performs; there is no domain left unmentioned.

Completeness

It explicitly answers both questions: the 'what' is the enumerated review checks ('Reviews eval scenarios and skills with judgement, covering what a deterministic gate cannot... Also grades the criteria an eval run left pending') and the 'when' is a concrete 'Use when' clause naming three trigger scenarios. This matches the anchor 5 example structure of concrete capability list plus explicit trigger phrases; not 4 because the when-clause is fully explicit rather than merely present.

Trigger Term Quality

Natural trigger phrases are present: 'review a pull request that touches a skill or an eval scenario', 'judge an eval run', 'check that a set of evals actually proves what it claims', along with domain terms like rubric, shim, and scenario. It falls short of anchor 5 because a few natural phrasings a user might say — 'grade the pending criteria', 'suite', 'audit' — appear only in the capability half or are absent from the trigger clause.

Distinctiveness Conflict Risk

The niche is distinct — judging eval scenarios, rubrics, recording shims, and eval runs is a clear specialty with trigger terms ('eval scenario', 'eval run', 'rubric') unlikely to fire for other skills. Even the PR-review trigger is narrowed to 'a pull request that touches a skill or an eval scenario', minimizing overlap with a generic code-review skill.