| name | verify-this |
| description | Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare, return VERIFIED, NOT VERIFIED, or INCONCLUSIVE. Use for /verify-this, "prove it works", "did this fix it", "show me the evidence". |
Verify this
Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.
When to use
- The user asks "verify this", "prove it works", "did this fix it", or "show me the evidence".
- A bug fix needs a before/after repro.
- A UI, CLI, API, performance, or memory claim needs measurement.
- A test passes but the user-visible behavior still needs confirmation.
Do not use this for vague claims like "the code is cleaner". Ask for a measurable claim first.
Workflow
- Restate the claim in falsifiable form: condition, metric, and threshold.
- Pick the smallest local surface that can disprove it.
- Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.
- Capture treatment from the changed state with the same command, data, warmup, and environment.
- Compare raw artifacts: numbers, screenshots, terminal transcripts, HTTP responses, profiles, heap snapshots, or test output.
- Return exactly one verdict:
VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Local surfaces
- Code behavior: focused unit/integration tests or a minimal repro script.
- CLI/TUI behavior: a terminal transcript of the real command.
- UI behavior: browser screenshots, page-text extraction, accessibility snapshots (see the
run skill and the sentinel check in pitfalls.md — confirm the page under test is serving the current code before trusting any capture).
- API behavior: local HTTP/RPC request and response diff.
- Performance: same-machine baseline/treatment timings or CPU profiles.
- Memory: heap snapshots before and after the suspected operation.
Prefer the text form of the evidence whenever the fact is text: page text, accessibility
snapshot, log line, test output, response body. Text diffs exactly and cites in one line, while
a screenshot of the same fact has to be re-read and described. Screenshot when the claim is
genuinely visual (layout, spacing, color, motion), and pair it with the text capture when both
apply.
Artifact layout
When safe to write artifacts:
.tmp/verify-this/<claim-slug>/
├── claim.md
├── baseline/
├── treatment/
├── diff/
└── verdict.md
If artifacts may contain sensitive code, prompts, screenshots, HTTP bodies, or heap data, keep only the minimal inline evidence unless the user agrees to disk storage.
Verdict rules
VERIFIED: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.NOT VERIFIED: the behavior is unchanged, moves the wrong way, or misses the threshold.INCONCLUSIVE: no valid baseline, noisy signal, failed measurement, or an environment difference invalidates the comparison.
Output
VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>
Evidence:
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>
Reasoning:
<one tight paragraph naming the evidence and any confounds>
Do not soften a negative result. A clear NOT VERIFIED is useful.
Adapted from the verify-this skill in cursor/plugins cursor-team-kit (MIT).
