Verify

verify: evidence, not confidence

A change is verified when its observable behavior matches its acceptance criteria, and you have seen that behavior yourself. "Should work", "compiles", "tests pass" are not that.

1. The floor: every gate green

Run the full chain and paste real results, not summaries of results: node checks/check.mjs, then the stack gates (typecheck, lint, tests, build; commands are in docs/standards/.md). Red gate → stop, fix, rerun. Never weaken a gate to pass it.

2. The point: exercise the change

• Take the spec's acceptance criteria (tier S: the request itself) and walk them end to end

in the closest thing to reality available: run the app, call the endpoint, click the flow, render the document. Per criterion: what you predicted you would see → what you did → what you observed. Write the prediction down before running. A pass you did not predict proves only that something happened; a prediction that turns out wrong is the finding, and the real behavior gets explained and traced to a rule before the criterion counts as met.

• Probe the edges the criteria imply: empty input, wrong input, unauthorized user, the second

run (idempotency), the slow path. The first bug is usually one step off the happy path.

• User-facing output → also run design-guard on what rendered. A built interface gets re-checked

against its direction contract and the finish verdict; a document, e-mail, export or error string gets judged there in full, because the design method does not carry those.

• Bug fix → reproduce the bug first on the old behavior (or its regression test), then show it

gone. A fix you never saw fail is a guess. Cause unknown, or a fix attempt already failed? Run the debug skill's loop before trying again.

3. What you cannot verify

Some things this environment can't exercise (production data, real payment, app-store review). Name them explicitly: "verified: A, B; not verifiable here: C, needs , tracked in STATE.md". Unverifiable-and-silent is how "works on my machine" ships.

4. Converge and record

• Substantial change (per code-review's own bar)? Hand the diff to code-review now, before

any status flips: findings must land while they can still change the work. Blocker fixes come back through §1-2. Trivial tier: record "code-review: skipped (trivial)" in STATE.md instead.

• Reconcile docs the verified change made stale; retired wording → denylist

(checks/config.json). Spec status → done, folder → archive (see spec).

• STATE.md: gates line updated with the evidence summary ("checks green, tests 61/61, criteria

4/4 exercised"), Now ▶ next step.

Report format, per criterion one line: ✓/✗ : , then the gates line, then anything unverifiable. No prose padding. ⚓

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Tradebaas
• Source: Tradebaas/Groundwork
• License: MIT
• Homepage: https://tradebaas.github.io/Groundwork/

Install and usage instructions live in the source repository linked above.