Conciseness

The body assumes competence throughout (no space is spent explaining what refactoring or invariants are) and uses dense, checklist-style txt blocks, but a few passages restate the same rule multiple ways — e.g., "The lane never widens silently... The evidence bar never drops" followed by the separate "Authorship is not the gate" paragraph, and the extended `untrack` discussion in Ownership And Collapse Check. These are trimmable over-explanations, matching anchor 4 rather than anchor 5's every-token-earns-its-place bar.

Actionability

For an instruction-only skill the guidance is fully actionable: literal templates to copy (Files-read ASCII tree, the Output Shape block with severity/file:line findings format), an exact smell checklist, a sample invariant-to-owner table, explicit one-caller guilt criteria, and a concrete prop/untrack design test. This matches anchor 5's specific-examples-cover-the-common-cases standard for guidance (per the code-vs-instruction scoring note).

Workflow Clarity

The Review Order is an explicit 10-step sequence with a validation checkpoint (step 9: run diagnostics/tests against a named baseline, with rules for attributing failures) plus a report-before-fix checkpoint (step 10), and the Output Shape section closes with a genuine feedback loop: "After edits, re-read every touched file and repeat the mental inlining, smell, invariant, and API checks. Report any new finding before fixing it." That is anchor 5 — clear sequence, explicit validation, error-recovery loop, and checklists.

Progressive Disclosure

The skill has no bundle files of its own, so all material belongs in SKILL.md, and the body is cleanly sectioned per pass (first-read, inlining, ownership, smell, invariant, API, naming, output). Its external references are one level deep and each is well signaled with a reason to load it — e.g., "cataloged in [typescript](../typescript/SKILL.md) 'Go-to-Definition Awareness'" and "[rethink's mental-inlining reference](../rethink/references/radical-options.md#mental-inlining)" — matching anchor 5's clear-overview, well-signaled one-level-deep reference pattern.

Specificity

The description lists three concrete review targets — "structural collapse, invariant ownership, and correctness" — in third-person voice, but stops short of comprehensive action coverage (what the review produces, or how findings are handled), which is the anchor-4 pattern rather than 5. It is well above anchor 3 because multiple distinct, specific capabilities are named rather than 1-2 generic actions.

Completeness

It explicitly answers both questions: what ("Review cumulative implementation for structural collapse, invariant ownership, and correctness") and when ("Use for reviewing work after implementation, doing a second pass, or performing a final sweep"), with concrete trigger phrases — a direct match for anchor 5. It also adds routing guidance ("Independent structural verdicts belong to adversarial-review"), which strengthens rather than weakens completeness.

Trigger Term Quality

"reviewing work after implementation", "doing a second pass", and "performing a final sweep" are natural phrases a user would say. A few common variations are missing (e.g., "review my changes", "code review", "post-review"), so this is good-but-not-comprehensive coverage: anchor 4, not 5; clearly above anchor 3's partial keyword set.

Distinctiveness Conflict Risk

The explicit hand-off "Independent structural verdicts belong to adversarial-review" carves out the nearest neighbor skill, but the phrase "reviewing work after implementation" still overlaps with generic code-review requests that several sibling skills could claim. Mostly distinct with minor overlap risk against closely related review skills — anchor 4 rather than 5's minimal conflict.