spec-verifylisted

Verify a completed feature spec by driving the real running app — not just lint/typecheck/build — and checking off every acceptance criterion from its specs/{feature}/ folder one by one. Use this after /spec-implement finishes a spec, when the user says "test this end to end", "verify this feature actually works", "did we actually build this right", or "/spec-verify", and before /spec-ship or opening a PR. This is the spec-aware sibling of the generic /verify and /run skills — /verify checks an arbitrary diff's runtime behavior and /run just launches the app, but this skill specifically reads a spec's requirements.md and task files, builds a master checklist of acceptance criteria, and reports pass/fail per criterion with real evidence (screenshots, API responses, DB state) instead of a vague "looks good." Always invoke this when a specs/{feature}/ folder exists and its implementation just finished, even if the user only says "does this work" or "test it."
benjaminthomas/spec-driven-dev · ★ 1 · AI & Automation · score 75

Install: claude install-skill benjaminthomas/spec-driven-dev

# Verify Feature Close the loop that `spec-create` → `spec-implement` leaves open: passing lint, typecheck, and build proves the code compiles, not that the feature does what the spec says it does. This skill reads a spec's acceptance criteria and checks each one against the actual running application — clicking through the UI, calling the real API routes, or inspecting real database state produced by the real code path. It produces a report the user can trust before shipping. ## When there's no spec folder If the user asks to verify a feature that wasn't built through `spec-create`, don't refuse — interview them briefly for what was built and what "working" means (the golden path, the edge cases they care about), then skip to [Step 3](#step-3-prepare-the-environment) treating their answers as the criteria list. The spec-driven path below is the common case, not the only one. ## Step 1: Locate the spec 1. If the user named a feature, use `specs/{feature}/`. 2. Otherwise look for a `specs/*/README.md` whose Task Status section is fully checked (all tasks `- [x]`) but has no `verification-report.md` sibling yet — that's the most recently completed, not-yet-verified feature. 3. If `spec-implement` hasn't finished all batches yet (some tasks still `- [ ]`), tell the user and ask whether to verify what's done so far or wait for the rest — verifying half a feature can produce confusing false failures for criteria that depend on an unbuilt task. ## Step 2: Build th