Conciseness

The body is dense with non-obvious, domain-specific rules (the tessl manifest recipe, the `scenario-N` downloader-collision rationale, shim flag-parsing like 'taking the token after a value-taking flag as that value even when it starts with `-`') and assumes competence, with no padding explaining concepts Claude already knows. It falls short of 5 only through minor redundancy: 'Never grade behaviour the unit does not document' appears in section 3.7 and again in Non-goals, and the HARD BOUNDARY overlaps the frontmatter's 'never restructures plugins'.

Actionability

Executable commands appear throughout ("jq '[.checklist[].max_score] | add' returns exactly 100", "git worktree add .worktrees/eval-<plugin> -b evals/<plugin> HEAD", "make test && make validate") plus exact JSON templates for scenario.json and criteria.json. It is not 5 because the two trickiest artifacts — inputs/setup.sh and the recording shims — are specified by description rather than shown as copy-paste code, and the worked example lives outside the skill bundle ('See the git-workflow PR scenario').

Workflow Clarity

Seven clearly sequenced phases (inventory, structure, design, offline gradeability, verification ladder, commit, batching) with an explicit checklist section headed 'run ALL before claiming done' containing exact commands and expected outcomes, plus explicit error-recovery and stop conditions ('If it fails for reasons unrelated to your scenarios, stop and report - do not modify manifests'). Batch and destructive operations (committing, temp-dir cleanup) are validation-gated, so the destructive/batch cap does not apply. Not 4: validation checkpoints are pervasive, not just present.

Progressive Disclosure

The body is well-sectioned (##/###) with clearly signaled, one-level-deep external pointers ('plugins/git-workflow/evals/ in this repository is the canonical worked example - read one of its scenarios before writing new ones') and no nested reference chains. It is not 5 because no bundle reference files exist (no references/, scripts/, or assets/), so dense detail such as the shim specification and the section 7 orchestrator batching notes is inlined in a ~220-line body that could be split; it is not 3 because the inlined material mostly belongs in the main workflow file and organization is good.

Specificity

Multiple specific concrete actions with comprehensive coverage: 'Generates and verifies eval scenarios', 'Authors self-gradable scenarios, runs the offline verification ladder, and commits', anchored by concrete artifacts '(task.md, criteria.json, scenario.json)' and the runner '`tessl eval run`'. Not 4: the coverage spans generation, verification, grading mode, and commit with no minor gaps in the skill's scope.

Completeness

Explicitly answers both questions: what ('Generates and verifies eval scenarios for a repository plugin... Authors self-gradable scenarios, runs the offline verification ladder, and commits') and when ('Use when the user asks to build evals for a plugin, generate eval scenarios, or verify that a skill actually works') with three concrete trigger phrases. Matches the top anchor exactly.

Trigger Term Quality

Natural phrases users would say are present: 'build evals for a plugin', 'generate eval scenarios', 'verify that a skill actually works', plus 'evals', 'plugin', 'skill' as domain keywords. Not 5: common variations such as 'write evals', 'test scenarios', or grading-oriented phrasings are absent as explicit triggers; not 3: the included keywords are relevant and natural rather than missing common variations.

Distinctiveness Conflict Risk

A clear niche (tessl-compatible plugin evals) with an explicit boundary ('This skill never restructures plugins'), but the trigger 'verify that a skill actually works' is broad enough that a user wanting ad-hoc manual verification could invoke the skill wrongly — minor overlap risk with a closely related testing/verification skill. Not 5 for that reason; not 3 because the domain and other triggers are far more specific than generic.