Conciseness

Lean throughout: no explanations of concepts Claude already knows, every section carries non-obvious project-specific guidance (vendored path rules, the '/manuals' prefix mapping, the specificity contrast example). The 'Notes' section is brief and each line changes behavior rather than padding. Matches the lean/every-token-earns-its-place anchor.

Actionability

Concrete, executable guidance dominates: a complete 'gh issue view' command with flags, exact read-only paths ('_vendor/', 'data/cli/', 'content/reference/cli/'), a live-site URL template, and a good/bad specificity example. Not a 5 because step 2 ('Search content/ using the URL or topic') gives no concrete search command or example, and the '/manuals prefix mapping' is alluded to rather than shown. Well above the pseudocode midpoint.

Workflow Clarity

A clear 7-step sequence with explicit validation checkpoints at every risky point: confirm the candidate file 'contains the reported problem' (step 2), verify editable ownership before planning edits (step 3), 'Do not plan a fix based on an unverified claim' and 'report it as a blocker rather than guessing' (step 5). These verification and blocker-reporting feedback loops match the top anchor; this is a research (non-destructive) skill so the destructive-cap rule does not apply.

Progressive Disclosure

A single well-organized ~70-line body with clean numbered sections and no monolithic inlining; the only external pointer ('See the vendored content table in CLAUDE.md') is one level deep and clearly signaled. No bundle files exist and none are needed — the structure satisfies the no-external-references case. Easy to navigate; matches the top anchor.

Specificity

Names the domain (documentation research) and several concrete actions — 'locate affected files, understand the problem, identify what to change' — but 'understand the problem' is generic and the action list omits steps the body actually covers (verifying claims, checking vendored ownership). Not a 5 because coverage is not comprehensive; not a 3 because it lists several specific actions beyond the 1-2 the midpoint anchor requires.

Completeness

Explicitly answers both: 'what' ('locate affected files, understand the problem, identify what to change') and 'when' ('Use when investigating an issue, a question, or a topic before writing a fix') plus concrete trigger phrases. This is a direct match for the top anchor; a 4 would require the 'when' to be less explicit than it is.

Trigger Term Quality

Natural, varied trigger phrasings users would actually say: 'research issue 1234', 'investigate what needs changing for #500', 'what files are affected by #200', 'where is X documented', 'is our docs page about Y accurate', 'look into how we document Z' — covering synonyms (research/investigate/look into) and both issue-driven and open-ended phrasings. Clearly matches the comprehensive-coverage anchor; nothing material is missing.

Distinctiveness Conflict Risk

Docs-specific triggers ('where is X documented', 'is our docs page about Y accurate') create a clear niche, but 'investigating an issue, a question, or a topic' is broad enough to overlap with general research/debugging skills. Mostly distinct with minor overlap risk; not a 5 because the generic 'investigate a topic' framing is not uniquely docs-bound.