Conciseness

The ~85-line body is dense, imperative, and spends no tokens on concepts Claude already knows — everything is proprietary CLI behavior. It stops short of anchor 5 due to minor trimmable redundancy: the destination-triage rule ("If that is the right destination but no deterministic tool exists, recommend the smallest conventional tool to add") appears nearly verbatim in both workflow step 5 and the Destination Triage section, and parts of Model Choice could be tightened. It is far above anchor 3, which requires unnecessary explanation rather than just duplication.

Actionability

Fully executable guidance throughout: copy-paste-ready commands (`tessl change verify --help`, `--recursive`, `--dry-run --all --show-files`, `--sample <n>`, `--github` with a deliberate `--max-calls`, `--model jev`), named models (`openai/gpt-6-luna`), and specific credential guidance (GitHub App installation token, fine-grained PAT with Contents/Actions permissions, classic PAT as last resort) covering the common cases. This matches anchor 5 rather than anchor 4, which requires minor gaps.

Workflow Clarity

The 9-step workflow has a clear logical sequence with an explicit decision point (step 2 classifies run-existing vs author-new), explicit validation checkpoints (step 4: lint → dry-run → sample before expensive/CI runs; step 6: backtest against representative PRs), and a closing feedback loop (step 9: use false positives, misses, and noisy scopes to tune wording, `relevant_when`, and globs) — a direct match for anchor 5's 'explicit validation steps; feedback loops for error recovery'.

Progressive Disclosure

The body is a genuine overview with a References section that signals all five bundle files (cli-usage, verifier-authoring, from-context-file, historical-pr-feedback, architecture-analysis) with one-line descriptions; every referenced path resolves to a real file, and the reference files link only sideways to siblings, keeping depth at one level. This matches anchor 5 ('clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation').

Specificity

The description enumerates multiple concrete, specific actions — "setting up verifier JSON checks", "authoring and tuning verifiers", "running lint/dry-run/sample/local preflight checks", and "rolling out CI verification gates for pull requests" — which comprehensively covers the command's lifecycle from authoring to CI rollout. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage' rather than score 4, which requires minor gaps in coverage.

Completeness

Both parts are explicit: what — the four enumerated actions; when — "Use for `tessl change verify`". This clears the score-4 anchor ('has both what and when; when could be more explicit or specific') but stops short of anchor 5 because the when-clause is a single narrow command trigger, lacking the varied concrete trigger phrases (e.g., mentions of verifier config, failing CI gates) that anchor 5 exemplifies. It is well above anchor 3, where 'when' is missing or only weakly implied.

Trigger Term Quality

Natural trigger terms are present and domain-appropriate: "verifier JSON", "CI verification gates", "pull requests", "lint/dry-run/sample/local preflight checks", anchored by the command name itself. It falls short of anchor 5 because a few natural variants users might say are missing (e.g., "tessl.json verify config", "verifier checks", "backtest verifiers"), but coverage is clearly good rather than merely adequate (anchor 3).

Distinctiveness Conflict Risk

The description is scoped to one specific CLI command (`tessl change verify`) with distinctive proprietary terminology, giving it a clear niche with minimal overlap risk against generic skills — a direct match for anchor 5. Nothing in it is generic enough to conflict with other skills, ruling out anchors 3 and below.