Generate an app verify skill

Leading words: interview the repo, drive like a user, feature map, prove one feature, skills/verify-app.

Every serious project needs a way to launch the app, exercise a feature as a user would, and keep evidence. This skill writes that as skills/verify-<app>/ (Agent Skills path — not .cursor/ only).

Copy these steps into the todo list verbatim. Skip with skip: <reason>.

1. Interview the repo (surface, run, drive, observe, isolate). Ask the user only what you cannot observe.
2. Write skills/verify-<app>/SKILL.md with Launch, Doctor, Drive, Evidence, Cleanup, Helpers. Helpers live under helpers/ (not scripts/). A Launch helper is required even when the app is a one-shot CLI (ready signal = usage line + exit).
3. Seed a feature map (features/README.md + 3–5 user-POV feature files).
4. Run launch → doctor → drive one mapped feature → evidence still exists after cleanup.
5. Point at /refreshing-app-verify.

If the checkout does not start, fix that first (or report it). A skill written against a broken base teaches the wrong steps.

Interview

• Surface: web UI, CLI/TUI, desktop, API, mobile? Pick the primary.
• Run: the repo's own documented dev command. Ports, env, seed, auth.
• Drive: existing harness first (Playwright, expect, curl). Then browser/CDP, PTY, or HTTP.
• Observe: screenshots, transcripts, bodies, logs, exit codes, DB.
• Isolate: can two instances run? If not, say so — refuse to double-drive a shared session.

Generated skill

Frontmatter: name: verify-<app> and a description that names the app and surface. Sections with no placeholders:

• Launch — exact command, ready signal, teardown.
• Doctor — read-only "is this instance worth driving?"
• Drive — real selectors/commands from this repo. ARIA, data attributes, prompt strings, routes — not coordinates.
• Evidence — what to capture and where. Real user path, not internal setters. Side effects counted. Mocks only at a production boundary.
• Cleanup — kill what you started. Evidence survives.
• Helpers — executable; invocation shown in the body.

Feature files use four H2s: Sub-features / How to get to it (user POV) / Driving it with the harness / Gotchas. Shape: references/feature-map.md.

Reply contract

Paths written, which feature you proved, where the evidence lives, and that cleanup left the evidence in place.