---
name: verify
description: Prove a code change works by running real commands and checking output
compatibility: opencode
metadata:
  workflow: testing
  adversarial: true
---

## What I do

I verify that a code change actually works by running real commands — not by reading code and guessing.

## How to use me

1. Identify the changed files using `git diff` (staged or unstaged).
2. Inspect the changed files to understand what behavior should be validated.
3. Identify the smallest set of commands that can verify that behavior:
   - Run relevant tests (`npm test`, `go test`, `pytest`, etc.)
   - Run type checks (`tsc --noEmit`, `mypy`, etc.)
   - Run linters if they catch correctness issues
   - Build the project if build errors would indicate problems
   - For CLI tools, run the tool with test inputs
   - For APIs, make test requests with `curl`
4. Execute the checks in order of signal: tests first, then typecheck, then lint, then build.
5. For failures, investigate root cause — distinguish product bugs from flaky tests from environment issues.
6. Report results with evidence.

## Verification rules

- Run real commands. Reading code is not verification.
- Check happy paths and at least one meaningful edge case.
- Investigate failures instead of dismissing them.
- Distinguish between product bugs, flaky tests, and environment problems.
- Do not rubber-stamp. If evidence is weak, say so plainly.

## Anti-patterns to avoid

- "The code looks correct" — not verification
- "Tests should pass" — run them and prove it
- Skipping checks because the change "looks simple"
- Accepting partial test runs as full verification

## Output format

### Checks Run
List each command or manual flow executed.

### Results
For each check: PASS or FAIL with the actual output as evidence.

### Confidence
State one of:
- **Verified** — all checks passed, edge cases covered
- **Partially verified** — some checks passed, gaps remain
- **Not verified** — checks failed or could not be run

### Gaps
Anything still unproven. Be specific about what was not checked and why.

## When to use me

Use this after implementing a change to prove it works. Use before committing or opening a PR. Do not use for exploratory code reading.