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:
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.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
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.
1---2name: verify-this3description: Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE.4---5
6# Verify This
7
8Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.
9
10## When To Use
11
12- The user asks "verify this", "prove it works", "did this fix it", or "show me the evidence".
13- A bug fix needs a before/after repro.
14- A UI, CLI, API, performance, or memory claim needs measurement.
15- A test passes but the user-visible behavior still needs confirmation.
16
17Do not use this for vague claims like "the code is cleaner". Ask for a measurable claim first.
18
19## Workflow
20
211. Restate the claim in falsifiable form: condition, metric, and threshold.
222. Pick the smallest local surface that can disprove it.
233. Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.
244. Capture treatment from the changed state with the same command, data, warmup, and environment.
255. Compare raw artifacts: numbers, screenshots, terminal transcripts, HTTP responses, profiles, heap snapshots, or test output.
266. Return exactly one verdict: `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE`.
27
28## Local Surfaces
29
30- Code behavior: focused unit/integration tests or a minimal repro script.
31- CLI/TUI behavior: `control-cli`, terminal transcript, or demo recording.
32- UI behavior: `control-ui`, screenshots, accessibility snapshots, or browser traces.
33- API behavior: local HTTP/RPC request and response diff.
34- Performance: same-machine baseline/treatment timings or CPU profiles.
35- Memory: heap snapshots before and after the suspected operation.
36
37## Artifact Layout
38
39When safe to write artifacts:
40
41```text
42/tmp/verify-this/<claim-slug>/
43├── claim.md
44├── timeline.md
45├── baseline/
46├── treatment/
47├── diff/
48└── verdict.md
49```
50
51If 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.
52
53## Verdict Rules
54
55- `VERIFIED`: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.
56- `NOT VERIFIED`: the behavior is unchanged, moves the wrong way, or misses the threshold.
57- `INCONCLUSIVE`: no valid baseline, noisy signal, failed measurement, or an environment difference invalidates the comparison.
58
59## Output
60
61Use this shape:
62
63```text
64VERIFIED | NOT VERIFIED | INCONCLUSIVE
65Claim: <falsifiable claim>
66
67Evidence:
68<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>
69
70Reasoning:
71<one tight paragraph naming the evidence and any confounds>
72```
73
74Do not soften a negative result. A clear `NOT VERIFIED` is useful.