Conciseness

No passage explains anything Claude already knows; the densest asides are non-obvious domain facts ("a target ending in `\` is an alias inside a table cell — where Obsidian requires the pipe escaped so the table does not split on it", "it indexes `main`, not this branch"). Rule statements carry their rationale in a single clause ("rewriting a page while reviewing it is how this family of drift starts"), so every token earns its place — matching the lean/efficient anchor rather than the minor-trimmable over-explanation of a 4.

Actionability

Every check has a copy-paste shell form: the heredoc report skeleton, `BASE=$(git config --get branch.$(git branch --show-current).gh-merge-base || echo main)`, the `comm -23` broken-wikilink pipeline, and the claim-shape table mapping each pattern to an exact command (`git grep -l '"name": "@scope/name"' -- '**/package.json'`). The finding block is a literal fill-in template, and the final `grep -c` checks are executable as written.

Workflow Clarity

Steps 0–5 are explicitly numbered with per-step report-writing instructions ("Write `## Scope` now"), and validation is explicit with error recovery: "Both must print `3`. A first count under 3 means a section was renamed or demoted; a second count above 3 means you added a top-level section". The "No step is a stop" section supplies a feedback loop for environment failure ("Every check below has a shell form; use it"), and the external checklist covers the complex `--full` process.

Progressive Disclosure

The single bundle file `references/checklist.md` exists and its headings (currency, bloat, aids, structure, frontmatter, links, hygiene) match the body's description verbatim; it is referenced once, clearly signaled with its content and trigger condition ("on a `--full` sweep, work through it page by page"), and is one level deep with no nested references. The inline body is exactly the per-run core procedure — the appropriate split, matching the clear-overview/well-signaled-references anchor.

Specificity

"Cross-checks every claim a page makes against the code, finds wikilinks and heading anchors the branch broke, checks frontmatter and page shape, and reports D-C/H/M/L findings in the four-field format" enumerates four distinct concrete actions plus a named output taxonomy — comprehensive coverage, matching the multiple-specific-concrete-actions anchor. Not a 4: no core capability of the review is left unspecified.

Completeness

Both halves are explicit: "Use when reviewing the documentation a branch changes — AGENTS.md, READMEs and pages under wiki/ — or sweeping the whole wiki with --full" (when, with concrete trigger phrases) and the enumerated action list (what). Matches the clearly-answers-both anchor; a 4 would require a less-explicit or less-specific 'when' clause.

Trigger Term Quality

Good natural keyword coverage — "reviewing the documentation a branch changes", "AGENTS.md", "READMEs", "wiki", "--full", "frontmatter", "wikilinks" — but a few natural terms users would say are missing: the colloquial "docs", the ".md" file extension, and "stale"/"broken links" phrasings. Not a 5 (that anchor requires synonyms and file extensions); clearly above a 3, which permits only partial keyword coverage.

Distinctiveness Conflict Risk

The description carves a clear niche — branch-scoped documentation review with code cross-checking and the D-C/H/M/L finding taxonomy — and its triggers name specific artifacts (wiki/ pages, AGENTS.md, branch diff, --full) that would not fire for a code review or generic docs-editing skill. Minimal conflict risk.