Conciseness

The ~20-line body is lean with no padding and no explanation of concepts Claude already knows — every line ("Check process liveness directly, not through a derived 'it should be up.'", "When a check fails, suspect the observation method before suspecting the product") adds non-obvious, project-specific guidance. It matches the anchor-5 'every token earns its place' case; anchor 4's 'minor instances of over-explanation' does not apply.

Actionability

The guidance is concrete and directive — "Run the feature, read the actual value, and inspect the diff", "reading back its exact bytes is the proof", with a clear decision rule for when to write a proof script versus when reading suffices. Per the rubric's instruction-skill note the absence of code is not penalized, but it stops short of fully executable copy-paste material (e.g., no example of what a re-runnable comparison script looks like), which keeps it below anchor 5.

Workflow Clarity

This is a simple single-purpose skill and its single action — verify the real artifact, not proxies — is unambiguous, with an explicit failure-handling rule ("suspect the observation method before suspecting the product") and clear conditionals for script vs. byte-read proof, artifact visibility, and when to commit. Under the rubric's simple-skill exception the single action being unambiguous warrants a 5; the operations are not destructive or batch, so no cap applies.

Progressive Disclosure

The skill is under 50 lines, requires no external references (none exist in the bundle), and is well organized into a header, a concrete checklist, a decision rule for proofs, and scoped special cases (commit policy, UI tasks). This matches the rubric's guideline that short skills with no need for external files can score 5 with well-organized sections alone.

Specificity

"Prove a task against the real artifact" names the domain (verification) and one core action, but the description never enumerates the concrete verification actions (run the feature, read values, inspect diffs, check liveness) that the body actually covers. Not a 4 because it does not list several specific actions; not a 2 because the action stated is more concrete than a generic 'handles verification'.

Completeness

The 'what' is clearly stated ("Prove a task against the real artifact before calling it done") and the 'when' is explicit with concrete trigger phrases ("Use during factory-work, before ready_for_review, and whenever a check only shows that code compiles or a file changed"). Both halves are explicitly present, matching the anchor-5 example structure; anchor 4's caveat (a less explicit 'when') does not apply.

Trigger Term Quality

Triggers like "factory-work", "ready_for_review", "code compiles", and "file changed" are relevant to this workflow but are internal jargon rather than natural user phrasings, and common variations ("verify", "test it", "before you call it done") are absent. Anchor 4 is not reached because keyword coverage lacks natural synonyms beyond the workflow-specific terms.

Distinctiveness Conflict Risk

The niche (artifact-level proof vs. proxy checks) is distinct and its triggers are tied to specific workflow states, giving it a clear identity. However, "prove a task" and failure-checking guidance could overlap with generic testing/verification skills, so it falls short of minimal conflict risk at anchor 5.