Conciseness

The body is lean, sectioned, and free of explanations of concepts Claude already knows; every section adds stage-specific contract detail. Not a 5 because the 'When to use' section restates the frontmatter description verbatim ("Use when status is confused, work resumed after drift, evidence lanes disagree, or a closeout claim may be stale"), a duplicated line that could be trimmed; not a 3 because there is no padded or unnecessary explanation beyond that one redundancy.

Actionability

Concrete guidance throughout: an exact deliverable schema ("schema_version, stage, status, evidence_refs, blocked_by, and next_stage"), explicit classifications ("pass, fail, blocked, or not_checked"), and routing rules with failure modes. Not a 5 because the validation step says "run plugin validation and SDK proof commands from the repository wrapper" without naming the actual commands, leaving the executor to look them up; not a 3 because the guidance is otherwise executable and specific rather than pseudocode-level.

Workflow Clarity

The Procedure is a clear 5-step sequence with an explicit validation gate: "stop at the first failed required gate, classify the blocker, and do not proceed to downstream stages until the failure is resolved or explicitly waived," plus recovery routing ("a blocker with the smallest recovery step"). Not a 5 because "Run the smallest relevant local check" leaves the actual checkpoint command unspecified; not a 3 because fail-fast checkpoints and error-recovery routing are explicitly present, not implicit.

Progressive Disclosure

A short, well-organized body (~55 lines) with a clearly labeled References section of four one-level-deep links — "Stage contract: [contract](./references/contract.yaml)", "Eval cases", "Task profile", "Source context" — all of which exist in ./references/ with no scripts/ or assets/ directories to disclose. Content is appropriately split and navigation is trivial, matching the anchor-5 pattern; there is no inlined bulk content that should have been moved out.

Specificity

"Analyze stale or conflicting lifecycle state by separating local, PR, CI, review, tracker, artifact, and session truth" names the domain, a concrete action (separate evidence lanes), and enumerates all seven lanes near-comprehensively. Not a 5 because it lists only one core action verb and never states the concrete deliverable (reconciliation verdict or handoff); not a 3 because the lane enumeration goes well beyond '1-2 concrete actions, not comprehensive'.

Completeness

Explicitly answers both: what ("Analyze stale or conflicting lifecycle state by separating local, PR, CI, review, tracker, artifact, and session truth") and when ("Use when status is confused, work resumed after drift, evidence lanes disagree, or a closeout claim may be stale") with concrete trigger phrases — a direct match for the anchor-5 example pattern. Not a 4 because the 'when' clause is already fully explicit, not something that 'could be more specific'.

Trigger Term Quality

"Use when status is confused, work resumed after drift, evidence lanes disagree, or a closeout claim may be stale" provides four natural trigger phrases a Harness user would plausibly say. Not a 5 because common synonyms like 'conflicting status', 'out of sync', or 'state mismatch' are missing; not a 3 because coverage is genuinely good rather than partial.

Distinctiveness Conflict Risk

The niche (cross-lane lifecycle state reconciliation) and distinctive triggers ("evidence lanes disagree", "closeout claim may be stale") give it a clear niche, but the generic-sounding "status is confused" and the existence of sibling routing skills (e.g., sy-reframe, which the body says handles ambiguous stage routing) create minor overlap risk with closely related skills. Not a 5 due to that intra-family overlap; not a 3 because the lane taxonomy is far more specific than 'Works with document files'.