Evidence before assertion. A claim without a fresh command run behind it is not made.

Fast path: when the plan is one sentence and no spec file exists, the gate for that sentence's criterion is a closed list: the tests that exercise the change, the build, and the linter, not the rest of the suite. The changed path still runs end to end. A second failed gate on a fast-path task means the task was not obvious: stop and run drill on it.

Name the claim about to be made: "done", "fixed", "passes", "works".
Sort the claim. What a command can settle is verified here; a taste claim is not. When the claim is about quality (a design, or a quality surface, as rubric defines it), run the rubric skill for it once the whole work is claimed done, with any criteria the calling skill hands over, whether or not the commands come back green; a slice's gate leaves it for then. Rejecting a taste claim as unprovable is a routing failure, not a verdict.
Run the commands that would prove it false: the tests, the build, the linter, and the actual behavior that changed. The full gate (every test, the build, the linter) runs once per commit, on the tree about to be committed, except on the fast path, where the gate is the closed list above, and for a change with no runtime behavior (docs, comments, assets), where it is the build and the linter; inside a slice, the red-green loop runs only the tests that exercise it, and inside a phase the spec declares, a commit gates on the checks of the area it touches, and each phase's last commit runs the full gate.
When a spec exists at docs/specs/<slug>.md, gate it criterion by criterion and check the diff against its non-goals, as spec gate lays out.
Exercise the changed path end to end, not only its unit tests. If the change has a runtime surface, drive it. Open prove it works when the changed path's result is read through a proxy (a timestamp, a status file, a cached value, a screenshot, or a report from another agent), a check fails, or the work is a port or a migration.
Read the output. Passing means the output says passing, not that the command exited.
State what was run and what it showed. If it broke, say it broke, with the output. When the spec names an artifact, re-run it and show its result, not a description of an earlier demo; the claim rests on the gate's output, never on the artifact alone.

Rules:

verify