Verify This
- 1.1k installs
- 2.5k repo stars
- Updated August 5, 2026
- cursor/plugins
verify-this is a verification skill that produces fresh, repeatable evidence for developers who need to prove a specific change works (or fails) before merge or release.
About
verify-this is a verification skill that turns “prove it works” into a falsifiable claim with repeatable evidence. verify-this restates the claim in testable terms, captures a baseline and a treatment run against a running app or service, and compares concrete artifacts (routes, UI behavior, API responses, edge cases, and measurements). verify-this returns one of three verdicts—VERIFIED, NOT VERIFIED, or INCONCLUSIVE—so a developer can decide whether the change is actually correct. Developers reach for verify-this when tests pass but user-visible behavior is uncertain, when a bug fix needs a before/after repro, or when performance or memory claims require measurement instead of a recap.
- End-to-end change validation
- Running service and UI checks
- Regression detection pre-ship
- Agent-driven test execution
- Blocks false done claims
Verify This by the numbers
- 1,147 all-time installs (skills.sh)
- +194 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #512 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cursor/plugins --skill verify-thisAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.1k |
|---|---|
| repo stars | ★ 2.5k |
| Last updated | August 5, 2026 |
| Repository | cursor/plugins ↗ |
How do I verify a bug fix with evidence?
Confirm a change actually works before merge or release by exercising routes, UI, APIs, and edge cases against a running app or service.
Who is it for?
Developers who need a repeatable before/after verification against a running app or API.
Skip if: Developers who only want subjective claims like “the code is cleaner”.
When should I use this skill?
Invoke when the user asks to verify a claim or requests proof a change works with measurable evidence.
What you get
A falsifiable claim statement, baseline artifacts, treatment artifacts, an evidence comparison, and a VERIFIED/NOT VERIFIED/INCONCLUSIVE verdict.
- verification verdict
- baseline vs treatment evidence
- repro steps
By the numbers
- Returns 3 possible verdicts: VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Files
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
1. Restate the claim in falsifiable form: condition, metric, and 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: VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Local Surfaces
- 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.
Artifact Layout
When safe to write artifacts:
/tmp/verify-this/<claim-slug>/
├── claim.md
├── timeline.md
├── baseline/
├── treatment/
├── diff/
└── verdict.mdIf 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
Use this shape:
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.
Related skills
TddFollow test-driven development with a strict red-green-refactor loop when creating reliable features or fixing bugs.544k196k
Test Driven DevelopmentEnforce writing failing tests before any production implementation code.181k264kQaRun conversational QA sessions that turn user-reported bugs into well-written, domain-aware GitHub issues without manual ticket writing.179k196kMigrate To ShoehornAutomatically update TypeScript test files that rely on unsafe `as` type assertions by replacing them with type-safe partial objects from @total-typescript/shoehorn.164k196k
Webapp TestingVerify frontend behavior, debug UI issues, capture screenshots, and inspect logs of a running local web application using Playwright.123k165k
Playwright CliRun browser automation, generate element snapshots, inspect DOM attributes, and execute Playwright tests from the terminal.102k12.3kHow it compares
Pick this when you need falsifiable, repeatable evidence from baseline vs treatment runs, not a narrative summary.
FAQ
What does verify-this output?
verify-this outputs a falsifiable claim, baseline and treatment evidence, and a clear verdict. verify-this returns VERIFIED, NOT VERIFIED, or INCONCLUSIVE based on a repeatable comparison of artifacts gathered from a running app or service.
When should I use verify-this instead of summarizing changes?
verify-this should be used when a developer needs proof, not a recap. verify-this is designed for measurable claims like bug fixes, UI behavior, API responses, performance, or memory outcomes where a before/after comparison can be repeated.
What kind of claims should not use verify-this?
verify-this should not be used for vague, subjective claims. verify-this explicitly avoids claims like “the code is cleaner” because they cannot be falsified with baseline and treatment artifacts or measured evidence.