Conciseness

The body contains no explanations of concepts Claude already knows — every sentence carries skill-specific domain information, which keeps it out of anchor 2's "unnecessary explanations or padded sections". But it could be tightened enormously: the change-class paragraph ("`scripts/change-class` answers the wider question every gate, workflow and lane asks...") is a single ~450-word run-on with deeply nested clauses ("the revision the base end of the range resolves to included"), and much of its detail (queue-only internals, lane declarations, fallback fetch mechanics) duplicates material that `--help` and references/wiring.md already carry. This fits anchor 3's "mostly efficient but... could be tightened" rather than anchor 4, because the tightening needed is structural and substantial, not minor.

Actionability

The body gives a copy-pasteable invocation (".agents/skills/harness-ci/scripts/harness-only --event pull_request --base \"$BASE\" --head \"$HEAD\""), concrete mode flags ("--mode render-candidate", "--mode docs", "change-class --output FILE", "--lanes-from DIR", "--queue-only-default true"), the aggregate-needs flag set ("--skippable", "--waiver", "--lane JOB=LANE"), explicit exit-code and stream contracts ("exit `2` is a wiring error that prints no verdict"), and specific GitHub Actions patterns ("needs.changes.result != 'success'"). This matches anchor 4 ("mostly executable guidance; concrete code or commands with minor gaps"); it falls short of anchor 5 because the aggregate-needs call is described in prose rather than shown as a runnable command line, and several behaviors are only reachable via `--help` deferral.

Workflow Clarity

Validation checkpoints are a strength — the skill is built around fail-closed semantics, refusal causes with remedies ("cause=source-mirror-missing verb=source operation=refresh. The caller refreshes its sources before retrying"), and unmeasured-render handling — so this is not the validation-missing case of anchor 2. But the main workflow (run classifier, read the verdict line, wire the aggregate, handle refusals) is never laid out as a sequence: the body is organized by topic (modes, manifest schema, caller ownership, wiring pitfalls, verdict reading) and the wiring section is a list of failure rules rather than ordered steps. That matches anchor 3 ("sequence present but checkpoints missing or implicit" — here the sequence is implicit) rather than anchor 4's "clear sequence with most checkpoints present".

Progressive Disclosure

The one-level-deep references that exist are well signaled and real: references/wiring.md (427 lines) contains all three anchor-linked sections cited ("The endpoint expressions", "Per-lane verdicts", "The CI context"), and every script path named in the body (scripts/change-class, scripts/harness-only, scripts/aggregate-needs, scripts/lib/change-class.sh) exists in the bundle. But README.md and templates/ci.yml are referenced and absent from the bundle, and a large amount of reference-grade detail — the change-class mega-paragraph, the manifest-schema rules, the fallback-ownership mechanics — is inlined in SKILL.md where it belongs in wiring.md or `--help`. This fits anchor 3 ("some structure but could be better organized; content that should be separate is inline") rather than anchor 4.

Specificity

"Load to wire, tune, or debug a repo's changed-file CI skip" names a specific domain ("changed-file CI skip") and three actions ("wire, tune, or debug"), but the verbs are user-intent verbs rather than concrete operations — the actual capabilities (classifying diffs as harness-only/docs-only, naming a change class, validating skipped jobs) live in the separate `summary` field, not the description. It matches anchor 3 ("names domain and 1-2 concrete actions, but not comprehensive") better than anchor 4, whose examples list specific concrete operations like "extracts text, fills forms, converts pages".

Completeness

The "when" is explicit ("Load to wire, tune, or debug..." is a use-when trigger), but the "what" is only implied: the description says what the skill acts on ("a repo's changed-file CI skip") without stating what it does — classification, change classes, and aggregator validation appear only in the `summary` field. Anchor 3 ("clear 'what' but 'when' missing or weakly implied") is the closest fit with the roles reversed; it does not reach anchor 4 because the what is not clearly stated within the description itself.

Trigger Term Quality

The description carries some natural terms a user would say — "CI skip", "debug", "changed-file" — but misses common variations and synonyms such as "skip tests", "docs-only changes", "harness-only", "merge queue", or "required checks". This matches anchor 3 ("some relevant keywords but missing common variations or synonyms"), not anchor 4's "good keyword coverage; a few natural terms missing" — the missing set here is larger than a few.

Distinctiveness Conflict Risk

"a repo's changed-file CI skip" is a narrow, well-defined niche with essentially no overlap risk against other skills — a user asking about this is unambiguously in the right place. This clearly matches anchor 5 ("clear niche with distinct triggers; minimal conflict risk") and is not the vague, broad wording of anchors 2-3.