| name | verify-this |
| description | Prove a concrete behavior, performance, UI, CLI, API, or memory claim with fresh baseline-versus-treatment evidence and one explicit verdict. Use when asked to verify, prove, compare before and after, show evidence, or confirm that a fix works. Do not use for vague claims such as cleaner code, a full plan-based release verification, or a known bug that needs a red-to-green reproducer. |
Verify This
Verification is a falsifiable comparison, not a recap of what the agent believes
it changed. Turn one claim into a measurable check and preserve enough evidence
for another agent to repeat it.
Workflow
- Restate the claim as a condition, metric, and threshold. If the claim cannot
be measured, ask for a measurable form or classify it as
INCONCLUSIVE.
- Select the smallest local surface that can disprove it.
- Capture a baseline from the parent commit, merge base, current failing
reproducer, or unchanged fixture.
- Capture treatment with the same command, data, warmup, environment, and
measurement method.
- Compare raw artifacts: test output, timings, screenshots, HTTP responses,
traces, profiles, or heap snapshots. Do not compare summaries alone.
- Return exactly one verdict:
VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Evidence Contract
Record:
- claim and threshold;
- revision or baseline identity for both runs;
- frozen contract and stage identity when this result will feed later work;
- exact commands and input fixture;
- environment differences and skipped checks;
- artifact paths or hashes, with sensitive payloads kept outside public Git;
- the verdict and one short explanation of confounders.
For durable project work, use the repository's existing proof artifact location,
for example .agent/tasks/<task-id>/verification/<claim-slug>/. Temporary or
sensitive evidence may stay outside the repository; retain only safe metadata and
hashes in the project. Never put credentials, private prompts, customer data, or
heap contents in a public checkout.
Verdict Rules
VERIFIED: baseline and treatment move in the predicted direction, meet the
stated threshold, and have no material confound.NOT VERIFIED: behavior is unchanged, moves the wrong way, or misses the
threshold.INCONCLUSIVE: there is no valid baseline, the signal is too noisy, the
command failed, or the environments are not comparable.
Use this output shape:
VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>
Evidence:
<artifact or metric>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>
Reasoning:
<one tight paragraph naming evidence and confounders>
Boundaries
- Use
proof-verify when the work has frozen multi-criterion acceptance
criteria and needs a fresh-context verifier.
- When the claim becomes an input to another stage, seal it in
.proof/stage-ledger.json with the exact commit/tree and input/output digests.
A changed contract, source, or input invalidates that claim; an unavailable
later environment does not.
- Use
bug-reproducer when a concrete defect needs a minimal red-to-green test
and separate approval gates.
- Use
testing-strategy to choose test levels before running this comparison.
- A single green test is not enough for a performance, release, UI, or memory
claim unless it is the stated evidence surface.
Gotchas
- A different fixture, warm cache, compiler, or machine can invalidate a
baseline comparison; report it instead of smoothing it away.
- A missing baseline is not a passing baseline. Use
INCONCLUSIVE.
- A test can pass while user-visible behavior remains wrong; use the real CLI,
browser, API, or artifact boundary when that is the claim.
- Do not turn a failed comparison green with retries, wider tolerances, or a
changed workload unless the claim itself was explicitly re-scoped.
Troubleshooting
| Symptom | Likely cause | Action |
|---|
| No comparable baseline | Parent state or repro is unavailable | Report INCONCLUSIVE; capture a new baseline before changing the claim |
| Results vary between runs | Warmup, shared state, timing noise, or nondeterminism | Fix isolation and repeat with a fixed workload; record variance |
| Treatment passes but claim is still doubtful | Wrong evidence surface | Move to the real boundary or add one focused integration/UI/CLI check |
| Evidence contains sensitive data | Raw artifact is not suitable for Git | Keep it private and record only safe metadata or a hash |
Source
Adapted from Cursor Team Kit's MIT-licensed verify-this workflow:
https://github.com/cursor/plugins/tree/main/cursor-team-kit/skills/verify-this
