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