/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
- Intent check. Using the intent as ground truth, name any drift between the original goal and the current direction — with evidence.
- Plan check. Does the plan match the intent? Look for scope creep, missing steps, unstated assumptions, over-engineering. Cite specific sections.
- Execution check. Does the execution match the plan? Look for skipped steps, deviations, unplanned changes, incomplete work. Cite specific evidence.
- 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.)
- 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.
1---2name: verify3description: Formal phase gate — checks intent, plan, and execution artifacts for drift, then actively re-checks each load-bearing claim against its source (an agent's self-report of having checked is not evidence). Requires the intent and execution artifacts (the plan is optional; an absent plan short-circuits to a plan-not-found verdict). Produces structured output. Trigger when the user runs /verify or needs to decide whether to proceed to the next phase. Not /double-check (quick re-check of one claim), /reflect (informal thinking, no gate), or /insight-critique (advisory output review) — verify is the formal gate against intent, plan, and execution.4---56# /verify78`/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.910It 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`.1112> **Structured execution spec:** [`protocol.yon`](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.1314## Preconditions1516Two 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.1718## The five phases19201. **Intent check.** Using the intent as ground truth, name any drift between the original goal and the current direction — with evidence.212. **Plan check.** Does the plan match the intent? Look for scope creep, missing steps, unstated assumptions, over-engineering. Cite specific sections.223. **Execution check.** Does the execution match the plan? Look for skipped steps, deviations, unplanned changes, incomplete work. Cite specific evidence.234. **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.)*245. **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.2526## Routing2728The 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.2930## Boundary3132`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.3334> **Human output.** This skill's handler-facing output obeys the human-output35> contract (`human-output/SKILL.md`).3637> **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.
allemaar