mcpField
V
verify-this

verify-this

github.com/hachejTesting & quality162 installsUpdated 3d ago
Repository

About verify-this

Verify This is a skill for testing specific, falsifiable claims with repeatable evidence. It is intended for bug fixes and claims about app behavior, APIs, agent output, or performance, using before-and-after comparisons and a fixed verdict.

Key features

  1. 01Restate claims as measurable tests
  2. 02Compare baseline and changed states
  3. 03Inspect raw evidence artifacts
  4. 04Return one of three verdicts

Use cases

  1. 01Check whether a bug fix works
  2. 02Measure a page or API claim
  3. 03Compare agent output before and after
  4. 04Test a performance threshold

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/hachej/boring-stack --skill verify-this

After installing, type/verify-thisin Claude Code to confirm it loaded.

Details

From the project README

Verify This

Adapted from Cursor's cursor-team-kit/verify-this (MIT, see THIRD_PARTY.md), with this app's surfaces.

Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.

When To Use

  • The person asks "verify this", "prove it works", "did this fix it", or "show me the evidence".
  • A bug fix needs a before/after repro.
  • A page, API, agent-output or performance claim needs measurement.
  • A test passes but the user-visible behaviour 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 (below).
  3. Capture a baseline from the old state: the merge base, the parent commit, or the current broken repro (a git worktree of the base gets its own verify instance).
  4. Capture the treatment from the changed state with the same command, data and environment.
  5. Compare raw artifacts: numbers, snapshots, HTTP responses, run rows, eval tables.
  6. Return exactly one verdict: VERIFIED, NOT VERIFIED, or INCONCLUSIVE.

Local surfaces in this app

  • Code behaviour: a focused unit test (node --test test/unit/<file>).
  • The page: the app's journey (npm run build && npm run journey, see boring-app-template), or a browser driver (control-ui) for snapshot, screenshot, network-summary, trace.
  • The API and the wire: verify api <path> before and after.
  • What an agent writes: run the app locally (npm run dev) and drive it, or the evals of hachej/boring-stack for the expert's skill.
  • Performance: verify perf, or timings from the same machine for baseline and treatment.

Verdict Rules

  • VERIFIED: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.
  • NOT VERIFIED: the behaviour is unchanged, moves the wrong way, or misses the threshold.
  • INCONCLUSIVE: no valid baseline, noisy signal (agent outputs on 3 cases are noisy), 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. Never put real user data in an artifact you commit.

Comments

Markdown supported