# Verification Before Completion

> Verification checklist before marking work complete. Use when: finishing a fix, completing a review finding, validating a build, confirming a refactor.

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

---


# Verification Before Completion

Ensures fixes and changes are actually validated before declaring success. Prevents "it compiles so it works" thinking.

## Core Principle

Never mark work done based on absence of errors. Verify the **positive** — confirm the expected behavior exists.

## Verification Checklist

Before marking any task complete, verify:

### 1. Build Verification
- [ ] Code compiles without new warnings
- [ ] All existing tests still pass
- [ ] Package builds successfully (if applicable)

### 2. Behavioral Verification
- [ ] The fix actually addresses the reported problem (not just a related symptom)
- [ ] Expected output is produced (not just "no error")
- [ ] Edge cases considered: empty input, null handles, max values, concurrent access

### 3. Regression Check
- [ ] No existing functionality broken by the change
- [ ] API contract preserved (same inputs → compatible outputs)
- [ ] No new warnings from static analysis or formatters

### 4. Integration Verification
- [ ] Changes work across all affected layers (C → Python → CLI if applicable)
- [ ] Both system-installed and pip-installed paths work (for Python changes)
- [ ] Both RPM and DEB packaging still work (for build changes)

## Anti-Patterns

| Anti-Pattern | Reality |
|-------------|---------|
| "It compiles" | Compilation proves syntax, not correctness |
| "Tests pass" | Tests may not cover the changed path |
| "No errors in output" | Silent failures are the worst failures |
| "Works on my machine" | Check both install contexts |
| "The diff looks right" | Run the code, don't just read it |

## When to Use

- After fixing a review finding
- After completing a build/install cycle
- After refactoring code
- Before marking a subagent task as done