Conciseness

The body is mostly disciplined — every section carries guidance and there is no primer on concepts Claude already knows — but passages like "The purpose is not to select a familiar technique. The purpose is to decide how this system can reveal the truth of this particular change" and the two-paragraph introduction of the affordance concept are ornate and could be tightened. This is more than minor trimmable over-explanation (a 4) but well short of padded verbosity (a 2).

Actionability

The guidance is procedural ("State the behavior that needs to become true", "Derive possible evidence paths from the system itself") but operates entirely at a methodological altitude with no worked example, template, command, or concrete instantiation of an evidence path or affordance in a real project. It instructs rather than merely describes (above a 1), but the specific steps a reader would execute against an actual system are missing, matching the 'high-level hints' anchor.

Workflow Clarity

The six numbered steps are clearly sequenced and each carries an explicit "**Complete when:**" checkpoint — genuine validation gates, so this is above anchor 3 (checkpoints missing or implicit). It falls short of a 5 because there are no error-recovery/feedback loops (no 'if the evidence refutes the claim, do X') and the unnumbered "Set a verification budget" section is inserted between steps 2 and 3, disrupting the numbered flow.

Progressive Disclosure

No bundle files exist, and the ~107-line single-file body is well organized with clear section headers and consistent 'Complete when' closure criteria — good structure with content appropriately placed. The under-50-line exception for a 5 does not apply, and some detailed guidance (affordance design criteria, the budget rules) is dense enough that it could live in reference files if the skill grew, keeping this at anchor 4 rather than 5.

Specificity

The description names its domain (verification planning) and exactly one concrete action — "plan a credible project-specific verification path" — which matches the 'names domain and 1-2 concrete actions, but not comprehensive' anchor. It is a genuinely specific action rather than generic handling (above a 2), but it does not list several distinct actions like the 4-5 anchors do.

Completeness

Both halves are explicit: the 'what' is "plan a credible project-specific verification path" and the 'when' is "Use before implementing a feature, bug fix, refactor, or cross-system change" with concrete trigger contexts. It sits just below a 5 because the 'what' is a single, somewhat abstract action — 'credible', 'project-specific', 'path' are qualifiers rather than enumerated capabilities — leaving the what-side less concrete than the when-side.

Trigger Term Quality

"feature, bug fix, refactor, or cross-system change" plus "implementing" gives good coverage of natural user phrasings for change work. It falls short of a 5 because common verification synonyms users actually say — 'test', 'testing', 'verify', 'validate the change' — are absent, but the missing terms are few rather than systematic, matching anchor 4.

Distinctiveness Conflict Risk

Planning a verification path before implementation is a recognizable niche distinct from execution skills (testing libraries, code review, security review), and the trigger is scoped to pre-implementation planning. Minor overlap remains: 'before implementing a feature, bug fix, refactor' is broad enough to brush against general planning and test-planning skills, fitting 'mostly distinct; minor overlap risk' rather than the minimal-conflict 5.