Conciseness

The ~45-line body is dense directive prose with zero concept explanations aimed at what Claude already knows — every sentence adds a rule, a criterion, or a repo-specific instruction (e.g., "Never kill by process name; kill what you started"). Brief rationale asides like "a cleanup that eats the proof fails this step" encode norms rather than pad, so it sits at anchor 5 rather than anchor 4's 'minor instances of over-explanation'.

Actionability

As an instruction-only skill it gives fully concrete guidance: exact paths (".cursor/skills/verify-<app>/SKILL.md", "features/README.md"), exact required sections (Launch, Doctor, Drive, Evidence, Cleanup, Helpers), exact feature-file H2 headings, real tool candidates (Playwright/Cypress specs, expect scripts, PTY helpers, CDP), and a worked reference example to follow. There are no pseudocode gaps or vague directives, matching anchor 5 under the instruction-skill scoring note.

Workflow Clarity

The five numbered sections form a clear generate-then-verify sequence with explicit validation checkpoints and feedback loops: "Run its own instructions end to end once", "Fix what fails, and run the generated cleanup after every failed iteration too", and "After cleanup, confirm the evidence still exists at the named location". Gate conditions ("If the checkout doesn't build or start as-is, fix that first... before generating") place it at anchor 5.

Progressive Disclosure

The body is a well-sectioned overview that appropriately pushes the feature-map template into a real one-level-deep reference (references/feature-map-example/ with README.md, create-note.md, search.md, matching the shape described in section 3). It stops short of anchor 5 because the body's other link, "../../docs/harness/claude-code.md", resolves outside the skill bundle and cannot be navigated from the skill as shipped — a minor organization gap characteristic of anchor 4.

Specificity

The description names several concrete capabilities — "Generate a project-local verification skill that drives your app the way a user does" and "prove UI/CLI/service behavior" — grounded in specific deliverables rather than vague language. It falls short of anchor 5 because it does not enumerate a comprehensive list of distinct actions (the deliverable is a single generated artifact), but it clearly exceeds anchor 3's '1-2 concrete actions' with the drive/prove/generate verb set and scope qualifiers.

Completeness

Both halves are explicitly present: 'what' via "Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform" and 'when' via "Use for /create-verification-skill, 'make a control skill for this repo', or when a project has no scripted way to prove UI/CLI/service behavior" with concrete trigger phrases. This matches the anchor-5 example structure exactly; anchor 4's 'when could be more explicit' does not apply since three explicit triggers are listed.

Trigger Term Quality

The trigger clause includes natural phrasings users would actually say: "make a control skill for this repo", "no scripted way to prove UI/CLI/service behavior", plus the explicit command "/create-verification-skill". It is not anchor 5 because common synonyms such as 'e2e harness', 'smoke test', or 'drive the app' variations are missing, but coverage is clearly good rather than partial.

Distinctiveness Conflict Risk

"project-local verification skill" and "control skill" occupy a clear niche with distinct triggers ("no scripted way to prove UI/CLI/service behavior") unlikely to fire for general testing or documentation skills. Minor overlap with test-authoring skills exists but the 'no scripted way' condition differentiates it, fitting anchor 5 rather than anchor 4's 'minor overlap risk with closely related skills'.