verify

---
name: verify
description: Prove a claim of done, fixed, or passing before you make it. Run the commands and read their output. Read this skill before you say that work is done, fixed, or tested. Read it also after a small change. Use it before a commit or a PR. Use it also when the user asks to write or update the verification recipe of the app.
---

Evidence comes before a claim. Do not make a claim without a fresh command run behind it.

Fast path: when the plan is one sentence and there is no spec file, the gate is that sentence's criterion. Run only the tests that exercise the change, and still run the changed path end to end. When the gate fails a second time on a fast-path task, the task was not obvious. Stop, and run `drill` on it.

1. Name the claim that you are about to make: "done", "fixed", "passes", or "works".
2. Sort the claim. Verify here what a command can settle. Send a claim about quality to the `rubric` skill now, whatever the commands show. A claim about quality is about a design, a UI, a public interface, a name, or prose. To fail it as unprovable is a routing failure. Passing commands never pass it.
3. Run the commands that would prove the claim false: the tests, the build, the linter, and the behavior that changed. The full gate is every test, the build, and the linter. It runs once for each commit, on the tree that you are about to commit. On the fast path, the gate is the criterion of the sentence. Inside a slice, the test loop runs only the tests that exercise the slice. Inside a phase that the spec declares, a commit uses the checks of the area that it touches. The last commit of the phase runs the full gate.
4. When a spec exists at `docs/specs/<slug>.md`, gate each criterion separately. At the commit of a slice, gate the criteria that the slice touches. A criterion where a declared phase ends waits for the last commit of the phase. When you claim that the whole work is done, gate every criterion. Take each result from the last evidence record when its hash still matches the tree. Run the verification command of each criterion, and quote the output that proves it. For a criterion whose line names `rubric`, use the verdict of that judge. When you claim that the whole work is done, the criteria are items in the current task list. When no list exists and there are three criteria or more, create one. Mark an item done only on the output or the verdict that proves it. A criterion without proof stays open. Then check the diff against the non-goals of the spec. A change inside excluded scope fails the claim, even when the tests pass. A spec that still has an `## Open decisions` section is a draft. No claim stands against a draft. Send it back to `drill`.
5. Exercise the changed path end to end, not only its unit tests. When the change has a runtime interface, drive it, and keep what it showed. A runtime interface is a UI, a CLI, a TUI, or a service. Keep the command output, the logs, a screenshot, or a transcript. When the base branch has a recipe, drive the touched features with it, as [app-check.md](references/app-check.md) says. The recipe is a project skill named `verify-<app>`. Write or update that recipe only when the user asks, through the same reference. For a runtime interface with no recipe, offer in one line to write one. Read [prove it works](references/prove-it-works.md) when you read the result of the changed path through a proxy. A proxy is a timestamp, a status file, a cached value, a screenshot, or a report from another agent. Read it also when a check fails, or when the work is a port or a migration.
6. Read the output. Passing means that the output says passing, not that the command exited.
7. State what you ran and what it showed. If it broke, say that it broke, and show the output. When the spec names a demo artifact, run that artifact again to show the demo. Do not describe an earlier run. A demo shows that the change works, but it proves no criterion. So a script written on the branch can be the demo.

Rules:

- The default answer is reject. A claim is false until fresh output proves it. The word of the implementer is not evidence.
- Never make a claim from memory of an earlier run. The evidence record is the content hash of the working tree, plus each command and its saved output. Get the hash with `git ls-files -z -co --exclude-standard -- . ':!*.md' | sort -z | xargs -0 sha1sum | sha1sum`. On macOS, use `shasum` instead of `sha1sum`. When a test reads Markdown, remove the `':!*.md'` exclusion. A record whose hash matches the tree is fresh output, not memory. Use it again, and do not run its commands again. A commit, a switch back to the same tree, or an edit only to Markdown keeps the hash and record. `implement`, `debug`, `land`, and this skill use the record again. The next edit to a file in the hash makes the record invalid.
- Plan every command that a claim needs, and run each command once, in a single call. Then map the output onto the criteria. Each command writes its full output to a file: `> /tmp/verify-<hash>-<name>.log 2>&1`. Read and search that file. To run a command again to see more of its output is a duplicate run. Run independent commands at the same time. Commands are independent when they share no file, port, database, or build directory. A criterion is a reading of output that already exists, not another start of the test suite.
- A verification command is the test runner, the build, or the linter of the project. A script written on the same branch as the change is not a verification command. Reject a claim that depends on such a script, even when the script passes. A `verify-<app>` recipe counts only in the form that the base branch has. A recipe written or changed on the branch under claim is a script of that branch.
- Report a skipped check as skipped. Partial verification gets a partial claim. "Tests pass; behavior not exercised" is honest. "Done" is not.
- A claim that depends on a measured number states what limits the number, as [explain the number](references/explain-the-number.md) says. A measured number is a benchmark, a speedup, a latency, a size, a pass rate, or a count of runs.
- Review feedback is a claim. Verify it before you implement it. Check unclear feedback. Do not obey it without a check.

• SKILL.md 6 KB
• references/app-check.md 4 KB
• references/explain-the-number.md 1 KB
• references/prove-it-works.md 2 KB