/verify

/verify is a formal phase gate. It checks three artifacts against each other — the intent (the original goal), the plan (the stated approach), and the execution (what was actually done) — and reports whether they still align before you proceed.

It hard-gates on two of them: the intent and the execution. If either is absent it stops and names what is missing, rather than guessing. The plan is optional — when absent, verify reports status: plan-not-found rather than failing. For a softer pause with no artifact requirement, use /reflect; for a quick re-read of a single claim, use /double-check.

Structured execution spec: protocol.yon. It carries the canonical preconditions, step sequence, and routing as named, validatable records; this file is the human-facing explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

Preconditions

Two artifacts hard-gate the run: the intent and the execution. If either is missing, verify aborts and says so — there is nothing to align without both. The plan may be absent: when it is, verify skips the plan and execution checks and reports status: plan-not-found rather than failing.

The five phases

1. Intent check. Using the intent as ground truth, name any drift between the original goal and the current direction — with evidence.
2. Plan check. Does the plan match the intent? Look for scope creep, missing steps, unstated assumptions, over-engineering. Cite specific sections.
3. Execution check. Does the execution match the plan? Look for skipped steps, deviations, unplanned changes, incomplete work. Cite specific evidence.
4. Source re-check (active, per-claim — the load-bearing gate). For every load-bearing factual claim in the execution or output, re-open the source that would confirm or refute it and check it directly; revise the claim if wrong. A claim not re-checked against its source is reported unverified, never as passing. The agent's own report that it "already checked" is NOT evidence — only a fresh read of the source counts. When assessing a claim, pose it as a question ("Is X true, per the source?"), not a statement to confirm. When the claim is about a committed, built, or published artifact, re-check against the consumed form — the committed blob (git show <ref>:<path>), the built dist/tarball, or the published version — not the mutable working tree; a dirty tree or a stale dist can pass a claim while the committed HEAD / shipped artifact is broken (grepping the working tree is not verifying the commit). Exception: when uncommitted WIP is itself the artifact under verification, the working copy is the correct source. (Grounded in the critical-thinking arc: passive/optional verification lets false claims through; a mandated active re-check catches them. The consumed-artifact clause was added 2026-07-07 after /verify returned clean on a working-tree grep while the committed HEAD shipped two CLI verbs dead — same family as tsc-green≠verified and served-route-shadows-source.)
5. Report. Produce a structured verdict: clean (true/false), gaps, drifts, issues, and a status of clean | gaps-found | plan-not-found | incomplete | unverified. A clean: true verdict must cite evidence, must follow substantive analysis of all prior phases, and requires every load-bearing claim to have passed the phase-4 source re-check.

Routing

The verdict points to the next move: /investigate when issues were found, /plan-create when the run surfaced drift from the intent, and /github-sync when the verdict is clean.

Boundary

verify is the formal self-gate against intent, plan, and execution artifacts. It is not /cold-review (outside-agent review of work artifacts), not /insight-critique (advisory review of one output), and not /double-check (a quick targeted re-read of a single claim). A clean verdict is not a substitute for tests or a build where those are required. Verification is active and per-claim: a passive alignment pass, or an agent's self-report of having checked, does not satisfy it.

Human output. This skill's handler-facing output obeys the human-output contract (human-output/SKILL.md).

Self-improvement. On completion, run the Self-Improvement Protocol (self-improve/SKILL.md): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.