/verify-this

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

1. 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`. 2. Select the smallest local surface that can disprove it. 3. Capture a baseline from the parent commit, merge base, current failing reproducer, or unchanged fixture. 4. Capture treatment with the same command, data, warmup, environment, and measurement method. 5. Compare raw artifacts: test output, timings, screenshots, HTTP responses, traces, profiles, or heap snapshots. Do not compare summaries alone. 6. 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