Conciseness

The body is lean and dense with instruction: every sentence directs behavior ('Answer these from the codebase and only ask the user what you cannot observe', 'Never kill by process name; kill what you started') and nothing explains concepts Claude already knows. Rationale phrases are punchy and earn their place ('A generated skill that was never executed is a draft, not a deliverable'). Not anchor 4 because there is no padding to trim.

Actionability

Concrete, actionable guidance throughout: exact paths ('.cursor/skills/verify-<app>/SKILL.md', 'features/README.md'), required frontmatter fields, six named generated-skill sections with their content requirements, and four named H2s for feature files. Falls short of anchor 5 because, for an instruction-only generator skill, there is no fill-in template or worked snippet for the generated SKILL.md — the agent must compose each section from the descriptions, and helpers are specified only by requirement.

Workflow Clarity

Five numbered sections in a coherent sequence (interview → generate → seed map → prove → offer maintenance), with explicit validation and a feedback loop in section 4: 'Run its own instructions end to end once... Fix what fails, and run the generated cleanup after every failed iteration too', plus a pre-flight gate ('If the checkout doesn't build or start as-is, fix that first'). This matches the anchor-5 pattern (validate → fix → retry).

Progressive Disclosure

The body is under 50 lines with well-organized sections, and its single external reference ([references/feature-map-example/]) is real (README.md, create-note.md, search.md all present), clearly signaled as a markdown link, and exactly one level deep. Per the guidelines, this meets anchor 5.

Specificity

The description names the domain ('Generate a project-local verification skill that drives your app the way a user does') but describes essentially one action with elaboration rather than several distinct concrete actions. Base fit is anchor 3 (names domain and 1-2 concrete actions), but it is written in second person ('drives your app'), which the guidelines penalize by reducing specificity by 1. Not anchor 4 because no list of multiple specific operations is present; not anchor 1 because the action named is concrete, not vague.

Completeness

Both 'what' ('Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform') and 'when' ('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') are explicit, with concrete trigger phrases. This matches the anchor-5 example structure exactly; anchor 4 would require a weaker or less explicit 'when' clause.

Trigger Term Quality

Good natural keyword coverage: '/create-verification-skill', 'make a control skill for this repo', 'prove UI/CLI/service behavior' — phrases a user would plausibly say. A few natural synonyms are missing (e.g., 'test my app', 'e2e', 'smoke test', 'drive the app'). Not anchor 5 because common synonyms and variations are not comprehensively covered; not anchor 3 because the included triggers go beyond a bare domain mention.

Distinctiveness Conflict Risk

The niche is clear — generating a project-local verification/control skill — and triggers like 'make a control skill for this repo' and 'no scripted way to prove UI/CLI/service behavior' are unlikely to fire for unrelated skills. Not anchor 4 because there is no meaningful overlap with neighboring skills' trigger phrasing.