# Do It Verify

> Use when selecting evidence for a delivery claim, regression fix, installation, or branch closeout.

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

---


# Verify

Match evidence to the claim. A passing command establishes what that command
actually checked; it does not automatically establish user acceptance. Prefer
checks that exercise the affected behavior after the relevant change.

Consider whether evidence is stale, from another checkout, unrelated, simulated,
or incomplete. Local tests can establish local behavior without establishing
production operation. Reproduce the original symptom when verifying a bug fix;
exercise package and host integration when claiming an installation works.

Report the result and relevant check, plus material gaps or remaining risks.
Use NOT_VERIFIED when proof is missing, and explain what is missing. No fixed
acceptance table, status vocabulary, or report template is required unless the
user or project asks for one.

For branch closeout, inspect the intended diff and review state and follow the
user's authorized commit, merge, publication, or cleanup scope. Parent agents
integrate delegated results and verify the combined change. Hook silence and
diagnostic event records are not proof of completion.