Verify This

Verify This is a small skill with a strict output: one of VERIFIED, NOT VERIFIED, or INCONCLUSIVE. It exists to stop an agent from recapping what it did and calling that verification.

It ships in Cursor's cursor-team-kit plugin, authored by Eric Zakariasson. The plugin also includes CI, code review, shipping, control-cli, control-ui, test reliability, and cleanup workflows. This page covers verify-this only.

Source and revision

What the skill actually does

The workflow has six steps:

1. Restate the claim in falsifiable form: condition, metric, threshold.
2. Pick the smallest local surface that can disprove it.
3. Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.
4. Capture treatment from the changed state with the same command, data, warmup, and environment.
5. Compare raw artifacts: numbers, screenshots, terminal transcripts, HTTP responses, profiles, heap snapshots, or test output.
6. Return exactly one verdict.

The verdict rules are the useful part:

• VERIFIED: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.
• NOT VERIFIED: 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.

The output shape is fixed:

VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>

Evidence:
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>

Reasoning:
<one tight paragraph naming the evidence and any confounds>

It also suggests an artifact layout under /tmp/verify-this/<claim-slug>/ with claim.md, timeline.md, baseline/, treatment/, diff/, and verdict.md. If artifacts may contain sensitive code, prompts, screenshots, HTTP bodies, or heap data, it says to keep only minimal inline evidence unless the user agrees to disk storage.

The local surfaces it supports

• Code behavior: focused unit/integration tests or a minimal repro script.
• CLI/TUI behavior: control-cli, terminal transcript, or demo recording.
• UI behavior: control-ui, screenshots, accessibility snapshots, or browser traces.
• 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.

control-cli and control-ui are other skills in the same plugin, not dependencies bundled with verify-this. If you do not have them, use a terminal transcript or a browser tool you already trust.

Illustrative verification

This is a constructed example, not a run against a repository.

Claim: "The new memoization cuts the settings panel render from 180 ms to under 90 ms on the same machine."

1. Falsifiable form: condition = settings panel with 50 fields; metric = median render time over 20 runs; threshold = below 90 ms.
2. Surface: a local performance harness that mounts the panel and records render time.
3. Baseline: check out the parent commit, run the harness 20 times, save the raw timings.
4. Treatment: apply the change, run the same harness with the same machine, data, and warmup.
5. Compare: report median, spread, and delta. If the baseline was 180 ms and treatment is 120 ms, the claim misses the threshold.
6. Verdict: NOT VERIFIED, even though the change improved things. The threshold was part of the claim.

The skill says not to soften a negative result. A clear NOT VERIFIED is useful.

When to use it

• A bug fix needs a before/after reproduction.
• A UI, CLI, API, performance, or memory claim needs measurement.
• A test passes but the user-visible behavior still needs confirmation.
• You need to stop an agent from saying "verified" without artifacts.
• You have a claim that can be restated with a condition, metric, and threshold.

When not to use it

• The claim is vague, such as "the code is cleaner" or "the UX is better." Ask for a measurable claim first.
• You need statistical significance testing. The skill asks for repeated runs and confound checks, but it does not prescribe a hypothesis test.
• You cannot capture a baseline. Then the honest verdict is INCONCLUSIVE, not a guess.
• The measurement would require production credentials or customer data. Use a synthetic or local surface, or do not run it.

Install

npx skills add cursor/plugins --skill verify-this -a claude-code

Prerequisites and footprint

The skill is tiny. Its value depends on the agent actually capturing artifacts, not on the size of the instructions.

Limitations

• Short source. The page has to add the worked example because the skill is mostly a contract.
• No harness. It tells you what to capture, not how to instrument the app.
• No statistical method. Repeated runs and confound checks are required, but the skill does not define sample sizes or confidence intervals.
• Artifacts can leak. Screenshots, HTTP bodies, and heap snapshots may contain secrets or customer data. The skill says to minimize them; that is a policy, not a redaction tool.
• control-cli and control-ui are separate. The skill references them, but a partial install will not have them.
• It cannot rescue an invalid baseline. If the old state cannot be reproduced, INCONCLUSIVE is the correct output, not a workaround.

Verify it yourself

1. Read the verdict rules and confirm the skill does not allow a softer fourth verdict.
2. Run it on a claim you already know is false. It should return NOT VERIFIED, not a summary of the attempt.
3. Check whether it captures the baseline before the treatment. A treatment-only measurement is not a comparison.
4. Confirm the artifact path and sensitivity guidance. If you would not put the artifact in a ticket, do not write it to disk.
5. Try a claim with no measurable threshold. The skill should ask for one, not invent it.

Review transparency

This is an original guide with short attributed references. It does not reproduce the full skill text.

Related

• How to Vet an Agent Skill — verify a skill before trusting it
• Browser Testing with DevTools — capture UI evidence
• Debugging and Error Recovery — find the cause before verifying the fix
• Web Performance Audit — a measurement workflow
• Prompt Benchmarking — repeated-run discipline for prompts