← ClaudeAtlas

verifying-development-worklisted

Use before claiming any task is complete, fixed, or passing, and before handing finished work back to the user.
slowdini/slow-powers · ★ 2 · AI & Automation · score 68
Install: claude install-skill slowdini/slow-powers
# Verifying Development Work Claiming work is complete without verification is an assumption, not a fact. Handing work back without a review pass is a guess that the diff is the right diff. Finishing requires both: verification proves the code runs; review proves it's the right code. > **THE IRON LAW:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE. NO HANDOFF WITHOUT A REVIEW PASS OVER THE DIFF. > **Violating the letter of the rules is violating the spirit of the rules.** --- ## Finishing: Review, Verify, Then Handoff When you believe the work itself is done, run these finishing phases **in order**. Review comes first so any fixes happen before the evidence you hand back; verification comes next so the claim covers the returned code; integration choices come last because they belong to the user. 1. **Review and fix the diff** — follow the [code-review reference](references/code-review.md), including its comment-hygiene checks. Review catches what running can't: silent regressions, missed edge cases, leftover debug code, noisy comments, reuse or simplification. Fix or flag each finding. Once behavior-changing fixes are done, the code is frozen. A small diff never exempts this phase: review depth is sized *inside* the reference ("Size the review to the change") — a small change means a small review, never no review. 2. **Establish final verification evidence** — apply the Gate Function (below) to the frozen code. If you already have qualifying current-session