Verify

Evidence before claims, always. This skill runs commands and reads their output; it changes nothing, so a failure it finds routes to fix, never to a quiet repair here. Reading a write back is still reading: the write belonged to whoever was authorized to make it, and this skill never originates one.

The rule

A claim you have not verified in this turn is not a claim, it is a hope. If the command that would prove it has not run since the last change, the honest report is the actual state plus what is still unproven.

Violating the letter of the rule violates its spirit: a paraphrase, an implication, or an expression of satisfaction is a completion claim too.

The gate function

Before any statement that work is done, correct, or passing:

1. Identify the one command whose output proves this exact claim.
2. Run it fresh and in full. A narrowed re-run proves only the narrowed scope.
3. Read the whole output and the exit code, and count the failures rather than scanning for the word "pass".
4. Decide. If the output confirms the claim, state the claim with the evidence beside it. If it does not, state the actual status with the same evidence.

Skipping a step is not a faster verification, it is a different activity.

What proves what

Before a check counts

A check nobody has watched fail is machinery, not evidence. Look for the record of it failing — the implementor's red run from before the change, or a run against a throwaway copy with the guarded condition broken, never the candidate itself — and confirm the failure message names that condition rather than a typo, an unresolved import, or a selection that matched nothing. With no such record, the check is cited as unproven. Ask the same question of every check you cite: what would it say against a target that never existed, or one it could not reach? A check that passes when the thing it guards is absent or unreachable is fail-open — an empty read-back treated as clean, a suite that skipped, a probe that reads "not found" as success — and it proves nothing about the claim it was offered for.

On a gate that was already failing before the change, a raw failure count decides nothing. Take the failing set on the base you started from, take the failing set now, and claim only what the comparison supports: which failures are new and yours, and which were already there and are still there. The claim of no regression needs an empty new-failure set, stated beside the pre-existing ones by name.

Delegated work

A report from another agent is a pointer to evidence, not the evidence. Read the diff it claims to have produced and re-run the gate on the merged result. An agent that reports success having written nothing is the failure this row exists to catch.

Review verdicts are the same shape. SHIP is the only verdict that permits a completion claim. FIX-FIRST names gaps that must close and be re-reviewed; BLOCKED means the route changed and the claim is not available at all. Relay the verdict you received, never a softened version of it.

Red flags

Reach for this skill the moment you notice "should", "probably", or "seems to"; satisfaction arriving before output; a commit, push, or pull request forming without a fresh gate; exhaustion arguing that the remaining check is a formality. Each of those is the same event: the claim is running ahead of the proof.

Report

State the command, its exit status, and the claim it supports, in that order. Where expected evidence could not be captured, say which and why rather than leaving the gap silent.