2.2 KiB
2.2 KiB
name, description, compatibility, metadata
| name | description | compatibility | metadata | ||||
|---|---|---|---|---|---|---|---|
| verify | Prove a code change works by running real commands and checking output | opencode |
|
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
- Identify the changed files using
git diff(staged or unstaged). - Inspect the changed files to understand what behavior should be validated.
- 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
- Run relevant tests (
- Execute the checks in order of signal: tests first, then typecheck, then lint, then build.
- For failures, investigate root cause — distinguish product bugs from flaky tests from environment issues.
- 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.