harnesschangedbaseline-copies-2026-09-11greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: verify-this
name: "verify-this"
description: "Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE."
description: "Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE."
# Verify This
# Verify This
one opening paragraph in the skill's voice: proves one claim, a ticket at verifying's acceptance against its exact result or a standalone measurable claim; fires on 'verify this', 'prove it works', 'did this fix it' and the handoff from delivery-review; control-cli and control-ui supply a harness when needed, diagnosing-bugs the cause, record-architecture-decisions the decision at close; never explains in place of measuring; the grant covers local verification, not external actions or spending (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
This skill proves one claim. A ticket at verifying supplies its acceptance and exact result; a standalone request supplies a measurable claim of its own. It fires on "verify this", "prove it works", "did this fix it", and at the handoff from delivery-review. The harness, when the surface needs one, is control-cli's or control-ui's, and a simple captured invocation is often enough; the cause of a failure is diagnosing-bugs' to find; the durable decision at close is record-architecture-decisions'. It never explains in place of measuring: a general explanation needs authoritative knowledge, not a manufactured repository experiment. The request's grant covers necessary local verification; an external action or spending beyond it remains a decision for the owner.
Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.
Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.
## When To Use
## When To Use
7 unchanged lines
- The user asks "verify this", "prove it works", "did this fix it", or "show me the evidence".
- 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 bug fix needs a before/after repro.
- A UI, CLI, API, performance, or memory claim needs measurement.
- A UI, CLI, API, performance, or memory claim needs measurement.
- A test passes but the user-visible behavior still needs confirmation.
- 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.
Do not use this for vague claims like "the code is cleaner". Ask for a measurable claim first.
for a ticket the claim is an acceptance item against its exact result_commit, the baseline may be its base_commit, and the repository's own instruments are reused first; the verdict is recorded with its baseline, treatment and comparison in the promoted evidence and this contribution's account with checks beside their output, citing shared measurements; NOT VERIFIED returns the work to implementation, INCONCLUSIVE stays an explicit limit, VERIFIED with review supported lets the request owner complete the ticket; the Handoff section names consumes, produces and next
1. Restate the claim in falsifiable form: condition, metric, and threshold.
1. Restate the claim in falsifiable form: condition, metric, and threshold. For a ticket, the claim is an acceptance item against its exact `result_commit`.
2. Pick the smallest local surface that can disprove it.
2. Pick the smallest local surface that can disprove it, reusing the repository's own instruments first.
3. Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.
3. Capture a baseline from the old state: merge base, parent commit, the ticket's `base_commit`, failing branch, or current broken repro.
4. Capture treatment from the changed state with the same command, data, warmup, and environment.
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.
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`.
6. Return exactly one verdict: `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE`.
9 unchanged lines
## Local Surfaces
## Local Surfaces
- Code behavior: focused unit/integration tests or a minimal repro script.
- Code behavior: focused unit/integration tests or a minimal repro script.
- CLI/TUI behavior: `control-cli`, terminal transcript, or demo recording.
- CLI/TUI behavior: `control-cli`, terminal transcript, or demo recording.
- UI behavior: `control-ui`, screenshots, accessibility snapshots, or browser traces.
- UI behavior: `control-ui`, screenshots, accessibility snapshots, or browser traces.
- API behavior: local HTTP/RPC request and response diff.
- API behavior: local HTTP/RPC request and response diff.
- Performance: same-machine baseline/treatment timings or CPU profiles.
- Performance: same-machine baseline/treatment timings or CPU profiles.
- Memory: heap snapshots before and after the suspected operation.
- Memory: heap snapshots before and after the suspected operation.
## Artifact Layout
## Artifact Layout
upstream's OS temp layout is rooted at .greenline/tmp/verify-this/<claim-slug>/ during authorized repository work and promoted before handoff to .greenline/work/evidence/<work-id>/verify-this/<claim-slug>/ or .greenline/ledger/evidence/<contribution>/verify-this/<claim-slug>/, since an evidence reference into scratch never resolves; a read-only request keeps its artifacts in the system's temporary directory and writes nothing to the repository
When safe to write artifacts:
When safe to write artifacts, during authorized repository work:
upstream's OS temp layout is rooted at .greenline/tmp/verify-this/<claim-slug>/ during authorized repository work and promoted before handoff to .greenline/work/evidence/<work-id>/verify-this/<claim-slug>/ or .greenline/ledger/evidence/<contribution>/verify-this/<claim-slug>/, since an evidence reference into scratch never resolves; a read-only request keeps its artifacts in the system's temporary directory and writes nothing to the repository
/tmp/verify-this/<claim-slug>/
.greenline/tmp/verify-this/<claim-slug>/
├── timeline.md
├── timeline.md
├── baseline/
├── baseline/
2 unchanged lines
├── treatment/
├── treatment/
└── verdict.md
└── verdict.md
promotion of instruments and results to the work or ledger evidence home before handoff; a read-only request keeps its artifacts outside the repository, as control-cli and control-ui say for the same case
Promote the relied-on instruments and results together, before handoff, to `.greenline/work/evidence/<work-id>/verify-this/<claim-slug>/` for a ticket's verification, or to `.greenline/ledger/evidence/<contribution>/verify-this/<claim-slug>/` for standalone upkeep; an evidence reference into the scratch directory never resolves. A read-only request keeps its artifacts outside the repository and leaves repository files unchanged.
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.
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
## Verdict Rules
17 unchanged lines
- `VERIFIED`: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.
- `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.
- `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.
- `INCONCLUSIVE`: no valid baseline, noisy signal, failed measurement, or an environment difference invalidates the comparison.
Use this shape:
Use this shape:
VERIFIED | NOT VERIFIED | INCONCLUSIVE
VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>
Claim: <falsifiable claim>
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>
<one tight paragraph naming the evidence and any confounds>
<one tight paragraph naming the evidence and any confounds>
for a ticket the claim is an acceptance item against its exact result_commit, the baseline may be its base_commit, and the repository's own instruments are reused first; the verdict is recorded with its baseline, treatment and comparison in the promoted evidence and this contribution's account with checks beside their output, citing shared measurements; NOT VERIFIED returns the work to implementation, INCONCLUSIVE stays an explicit limit, VERIFIED with review supported lets the request owner complete the ticket; the Handoff section names consumes, produces and next (carried from fold-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
Do not soften a negative result. A clear `NOT VERIFIED` is useful.
Do not soften a negative result. A clear `NOT VERIFIED` is useful. Lead with the observed result, not an adjective standing in for a measurement.
Record the verdict with its actual baseline, treatment and measured comparison where the work owns them: the promoted evidence, linked from the ticket, and this contribution's account as `.greenline/ledger/README.md` defines it, whose `checks` reference the instruments beside their output. Cite a shared measurement rather than claiming a separate run, keep an unavailable proof explicit, and leave earlier completed review records as history. `NOT VERIFIED` returns the affected work to implementation; `INCONCLUSIVE` remains an explicit proof limit; `VERIFIED`, with the required independent review already supported, lets the request holder complete the ticket within its grant. A read-only request reports the evidence without repository writes.
Consumes: the ticket at verifying, its acceptance and exact result_commit
Produces: the verdict VERIFIED, NOT VERIFIED or INCONCLUSIVE with claim, baseline, treatment, diff and verdict files under .greenline/work/evidence/<work-id>/verify-this/<claim-slug>/ or .greenline/ledger/evidence/<contribution>/verify-this/<claim-slug>/; NOT VERIFIED returns the ticket to implementing
Next: the request holder completes the ticket; record-architecture-decisions and the decisions book close it