Initial project scaffold with uv

This commit is contained in:
2026-04-01 15:52:58 -07:00
commit f5ac0e04de
18 changed files with 1402 additions and 0 deletions

View File

@@ -0,0 +1,64 @@
---
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.