| name | verify |
| description | Run the project's deterministic checks and produce an evidence-backed proof report plus a machine-readable proof marker. Never modifies code (writes only its proof artifacts). Front door for /verify. |
| allowed-tools | Read, Grep, Glob, Bash, Write |
| tags | ["sdlc","qa","verify"] |
verify
Run the relevant deterministic checks from AGENTS.md/CLAUDE.md and produce proof. Deterministic
checks are the proof — the model's claim is not. Never modify code (you write only the
proof artifacts below).
Steps
- Discover the project's real commands (from
AGENTS.md/CLAUDE.md/scripts); don't assume.
- Bring up the env if integration/E2E need it (
stack up → seed → ready_check);
ensure teardown afterward.
- Run each check, capturing the exact command, exit code, and a short output tail.
- Stop at the first hard failure for the fast path, but still record what ran.
- Write the report + marker (below). Set overall
status = pass only if all required
checks passed.
- If anything failed, hand off to
/fix-loop — do not fix here.
Checks to run
Backend proof: lint · typecheck · unit tests · integration tests · migration check
(if applicable) · API contract (provider-side) validation · coverage vs the
coverage bar: 80% on changed code.
Frontend proof: lint · typecheck · unit/component tests · build ·
Storybook/component check (if available) · Playwright E2E · accessibility basics.
Report (stdout)
- exact commands run · pass/fail per command · the exact failed command (if any) · error
summary + suspected root cause · next recommended action.
Proof artifacts (this is what makes "done" checkable, not just claimed)
Also WRITE, to the artifact path(s) your instructions specify (the orchestrator passes them;
standalone, use a sensible dir you choose):
verify.md — the human-readable report above.last-verify.json — the marker, e.g.
{"status":"pass|fail","date":"<YYYY-MM-DD>","stack":"backend|frontend","checks":[{"cmd":"…","result":"pass|fail"}]}.
Nothing auto-runs this for you — it's on you (or /human-review-pack) to check the marker exists
and is fresh before treating an implementation as done. The proof is produced by this
command, not assumed.
Edge cases / pitfalls
- Flaky failure vs real: re-run once; if it passes intermittently, record it as flaky
and surface it — do not mark green and move on.
- Env not up / port in use — an environment error is not a passing test; report it distinctly.
- Partial pass — some suites green, one red → overall
status:"fail".
- Skipped/
todo tests or disabled checks — call them out; they are not proof.
- Coverage below threshold — a fail even if all tests pass.
- No tests found for changed code — a gap; report it rather than reporting success.
Definition of done
Never accept "everything works". Overall status reflects the weakest required check; the
marker and report are written; on failure the next action points at /fix-loop.
Output contract
Return status (pass|fail), report_path (the verify.md written), and failed_cmd
(the exact first failing command, empty string on pass).
