Verify

Verify runs your app and drives it through the path you just changed, then reports whether the change actually behaves as intended — closing the gap between "the test suite is green" and "the feature works." It exists for the specific failure mode where unit tests pass against mocks while the real UI throws on click, renders blank, or silently no-ops. Built for anyone landing a fix or feature who wants proof, not assumption, before pushing.

When to use it

• You've fixed a bug and want to confirm the broken flow now works end to end.
• A PR's CI is green but you don't trust that the user-facing behavior changed.
• A feature touches rendering, navigation, forms, or async state that unit tests stub out.
• You're reviewing someone else's change and want a screenshot of it actually running.

How it works

Verify detects the project type and launches it the way it's meant to run — npm run dev / vite for web apps, the configured start command for servers, the binary for a CLI. It prefers a project-local launch skill if one exists, then falls back to built-in patterns per stack.

Once the app is up, it drives the changed path through a browser/preview layer: starting a session, navigating to the route, clicking and filling elements by their accessibility snapshot, and reading back console logs and network requests. At each meaningful step it captures a screenshot so the result is visually inspectable. It then compares observed behavior against the stated intent of the change and reports pass/fail with the evidence attached.

Usage

curl -fsSL --create-dirs -o ~/.claude/skills/verify-skill/SKILL.md https://claudeskil.com/skills/verify-skill/SKILL.md

# then, in a session on your project:
verify "the date picker now allows selecting past dates"
verify --pr 482        # check out and verify a specific PR

A typical run: boots the dev server, opens the affected screen, exercises the control, grabs before/after screenshots, surfaces any console errors, and prints a verdict like PASS — past dates are now selectable; no console errors on selection.

Tips & gotchas

• Give it the intent, not just the file. "Submit button stays disabled until email is valid" verifies far better than "check the form."
• It needs a runnable app. If your dev server requires env vars or a seeded DB, set those up first or point Verify at a launch script.
• Screenshots are the receipts — skim them even on a PASS, since visual regressions (overlap, clipping) can pass a behavioral check.
• For flows behind auth, provide a test account or an existing logged-in session; Verify won't invent credentials.

FAQ

Does this replace my test suite? No. It's complementary. Tests guard against regressions cheaply; Verify confirms the real, assembled app does the thing — catching integration and rendering bugs tests miss.

What if the app won't start? Verify reports the launch failure with logs rather than guessing. That itself is a useful signal — a change that breaks startup is a fail.

Can it verify backend-only or CLI changes? Yes. For CLIs it runs the command and inspects output/exit codes; for servers it hits endpoints and checks responses. The UI-driving path is for apps with a frontend.