# Verification Gate

> Audit whether completed work actually supports its success claims. Use before saying a change is complete, fixed, passing, compliant, or ready when those claims can be checked. Do not use for early exploration, ideation, or requests that only ask for a plan.

- Skill: `denizaslan36/verification-gate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add denizaslan36/verification-gate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/denizaslan36/verification-gate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: denizaslan36 (https://skillmd.com/u/denizaslan36)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/denizaslan36/verification-gate

---


# Verification Gate

Match every important completion claim to fresh, proportionate evidence.

## Gate

1. Extract the claims the final answer would make. Include explicit acceptance criteria and important implied promises.
2. For each claim, identify the cheapest check that could disprove it. Prefer direct checks over proxies.
3. Run safe checks that are available and authorized. Read the exit status and relevant output; do not infer success from a command merely starting.
4. Map each claim internally to one status:
   - **verified** — direct current evidence supports it;
   - **partially verified** — evidence covers only part of it;
   - **not verified** — no adequate check was run;
   - **failed** — evidence contradicts it.
5. Resolve failed claims when the task authorizes implementation. Re-run the affected checks after any change.
6. Report the actual state. Never turn partial evidence into a complete-success claim.

## Evidence Rules

- Use the narrowest check that proves the claim, expanding only when risk or dependencies justify it.
- A linter does not prove a build; a build does not prove behavior; a passing unrelated test does not prove the reported bug is fixed.
- Old output, expected output, and another agent's assertion are leads, not fresh evidence.
- When a check cannot be run because of missing access, time, hardware, or credentials, name the limitation without assigning work to the user unless asked.
- Preserve exact failure details needed to diagnose the result, but never expose secrets.

## Final Form

Keep the report compact: outcome, evidence run, unresolved limitations. Show
per-claim statuses only when they clarify multiple claims or mixed results. For
a single straightforward claim, give the conclusion and decisive evidence in
plain prose; omit a checklist when a short sentence is clearer.