# Verify Completion

> Verifies implementations and fixes actually work by executing commands and observing real results. Never trusts claims. Use as the final quality check after implementation, after a bug fix, or when the user asks "is it done", "does it work", "verify this", or "confirm the fix".

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

---


<!-- sage-metadata
cost-tier: sonnet
activation: mandatory
tags: [verification, quality, completion, testing]
inputs: [implementation, test-suite]
outputs: [verification-result]
-->

# Verify Completion

Run the code. Run the tests. Observe the results. Don't trust claims.

**Core Principle:** An implementation is not done when the agent says "done."
It's done when evidence proves it works. Evidence means command output,
test results, and observable behavior — not descriptions of what should happen.

## When to Use

As the final gate (Gate 5) after spec compliance, constitution compliance,
code quality, and hallucination checks have all passed. Also after any bug fix,
before declaring the fix complete.

## Process

### Step 1: Run All Tests

Execute the full test suite. Not "I believe the tests pass" — actually run them.

```
Capture: exact command executed
Capture: complete output including pass/fail counts
Capture: any warnings or skipped tests
```

ALL tests must pass. If any test fails, the verification FAILS — even if the
failing test is unrelated to the current change (you may have introduced a regression).

### Step 2: Run Specific Acceptance Criteria

For each acceptance criterion in the spec:
- Execute the verification command or scenario
- Capture the actual output
- Compare against expected output

If the spec says "API returns 200 with user.id in body," actually call the API
and inspect the response. Don't just read the code and conclude it would work.

### Step 3: Verify Edge Cases

For FIX mode:
- Reproduce the original bug scenario. It must NOT reproduce.
- Verify the fix doesn't break related functionality.

For BUILD mode:
- Test the happy path AND at least one error path.
- Verify the feature works end-to-end, not just in isolation.

### Step 4: Produce Result

```
GATE: verification
RESULT: PASS | FAIL

EVIDENCE:
  Test suite: [X] passed, [Y] failed, [Z] skipped
  Command: [exact command run]
  Output: [relevant output excerpt]

ACCEPTANCE CRITERIA:
  ✓ [criterion 1] — Verified: [evidence]
  ✓ [criterion 2] — Verified: [evidence]
  ✗ [criterion 3] — FAILED: expected [X], got [Y]

ACTION: none | fix-and-retry | escalate-to-human
```

## Rules

- NEVER say "tests should pass" — run them and report what happened.
- NEVER say "I verified it works" without showing the command and output.
- NEVER skip verification because "it's a small change." Small changes cause outages.
- NEVER mark verification PASS if any test fails, even "unrelated" ones.
- If you can't run the verification (missing tool, environment issue), report
  it as BLOCKED, not PASS.

## Failure Modes

- **Tests pass but feature doesn't work:** Tests are incomplete. Write a new
  test that captures the actual failure, then fix.
- **Can't run tests (environment issue):** Report BLOCKED with details. Do NOT
  skip verification. Help resolve the environment issue first.
- **Flaky test fails:** Not acceptable. Flaky tests are bugs. Investigate
  with systematic-debug skill. Don't re-run and hope.