# Verify

> Use before any completion claim, commit, or PR — requires running verification commands and confirming output before making success claims

- Skill: `dodi-hq/verify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dodi-hq/verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dodi-hq/verify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dodi-hq (https://skillmd.com/u/dodi-hq)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/dodi-hq/verify

---


# Verify

**Core principle:** Evidence before claims, always.

If you haven't run the verification command in this message, you cannot claim it passes.

## The Gate

Before claiming any status:

1. **IDENTIFY** — what command proves this claim?
2. **RUN** — execute it (fresh, complete)
3. **READ** — full output, check exit code
4. **CONFIRM** — does output support the claim?
5. **THEN** — make the claim with evidence

## Common Failures

| Claim | Requires | Not Sufficient |
|-------|----------|----------------|
| Tests pass | Test output: 0 failures | Previous run, "should pass" |
| Build succeeds | Build output: exit 0 | "Linter passed" |
| Bug fixed | Reproduce original symptom: fixed | "Code changed" |
| Agent completed | `git diff` shows changes | Agent says "success" |
| Requirements met | Line-by-line checklist | "Tests pass" |

## Red Flags — STOP

If you catch yourself thinking any of these, run the verification:

- "Should work now"
- "I'm confident"
- "Linter passed" (linter ≠ compiler)
- "Agent said success"
- "Just this once"

Run the command. Read the output. THEN claim the result.

## Runner Delegation

Dispatch test execution to test-runner workers (see test-runner-prompt.md), one per test group, instead of running suites in the main loop — suite output floods context and blocks everything else. The gate is preserved: each runner returns a digest with commands, exit codes, failing test names, and a log path, and you claim results only from that evidence. A runner's "passed" without commands + exit codes is a worker success claim — reject it. Quick read-only checks (`git diff`, single-file inspection) stay in the main loop.

**Local-CI runner — required stage element:** alongside the per-group runners, dispatch the **local-CI runner** (`submit-ticket-pr/local-ci-runner-prompt.md`): repo-local gates (lint, typecheck, validation scripts named in the repo instructions) plus broader cross-area regression checks, with its discover-and-run mandate intact — where the Testing Contract's Broader-regression line is `to-be-discovered` or narrow, the runner's discovery obligation governs. Pass it a `groups-covered-elsewhere` scope note naming the test groups the per-group runners already cover, so the same suites are not run twice in one stage.

**Digest head-SHA rule:** every runner digest — per-group and local-CI alike — records the head SHA its commands ran against, so downstream gates can tie each green result to the exact tree state that produced it. A digest without its head SHA is incomplete evidence — reject it the same way as a missing exit code.

## Epic Orchestration Verification Rules

- Read the Testing Contract before choosing commands.
- Do not skip required unit, integration, or e2e groups because a harness is absent.
- Set up missing required harnesses when feasible.
- Classify failures as test bug, implementation bug, environment/harness issue, or spec/plan mismatch.
- Fix the right thing; do not default to editing tests.
- Return to the spec lane when verification exposes a spec/plan mismatch.
- For an epic full regression run before the epic PR, cover the union of all merged children's required test groups on the integrated epic head (after the latest main/master sync), not just one ticket's contract. Record the commands, exit codes, and the head SHA the suite ran against.