Verify

Skill allemaar/open-skills/skills/verify

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.From its SKILL.md

Install

npx -y skills add allemaar/open-skills --skill verify

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.6 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

/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.

What ships with it: 1 file

6.8 KB alongside SKILL.md

protocol.yon6.8 KB

Gives 0 of the 12 instructions most quality gates skills give in ~1.0k tokens

Counted across 1,195 of the 2,094 authors here whose files we hold, read 2026-08-07

Read the output and check the exit codein 54 of 1195, across 14 files
Verify requirements using a line-by-line checklistin 53 of 1195, across 12 files
Identify the verification command proving the claimin 51 of 1195, across 12 files
Run the full verification commandin 50 of 1195, across 11 files
Verify output confirms the claimin 49 of 1195, across 12 files
Check version control diff after agent delegationin 46 of 1195, across 6 files
State claim with evidencein 44 of 1195, across 4 files
Run the test suitein 33 of 1195, across 26 files
Keep state in memory by defaultin 27 of 1195, across 6 files
Make prototype runnable with one commandin 26 of 1195, across 5 files
Produce a verification reportin 25 of 1195, across 14 files
Detect the package manager from lockfilesin 24 of 1195, across 5 files

Said here and by no other author read

abort if intent or execution artifacts are missing
report plan-not-found status when the plan is absent
check for drift between intent and current direction
cite specific evidence when checking plan and execution
re-check every load-bearing claim against its source
revise any claim that the source refutes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.