Verification Before Completion

Iron Law: "NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE"

When to Use

This skill applies whenever you:

• Mark a todo item as complete
• Claim a bug is fixed
• Report a feature is ready
• State implementation is done
• Close a task or issue
• Prepare to commit changes

Red Flags (Violation Indicators)

• "should be done" / "should work now" (assumed completion)
• "probably works" / "likely fixed" (uncertainty without verification)
• "seems to work" / "appears correct" (observation without test)
• "Great!" / "Perfect!" / "All set!" (celebration without evidence)
• "I already tested this earlier" (stale evidence)
• Completion claim without test output shown
• Completion claim without grep verification for file changes
• Completion claim without screenshot for UI changes
• Completion claim without git diff for code changes
• Completion claim without build logs for configuration changes
• Completion claim without CI link for deployment changes
• "Just a small change, no need to verify" (size-based rationalization)

Key Concepts

Fresh Verification Principle

Verification must be fresh (performed after the claimed change) and explicit (evidence shown, not described).

Wrong:

Fixed the login bug in auth.ts. Should be working now.

Correct:

Fixed the login bug in auth.ts line 42:

git diff src/auth.ts:
-  if (user.token == null) {
+  if (user.token === undefined || user.token === null) {

Test output:
✓ should reject undefined token (15ms)
✓ should reject null token (12ms)
✓ should accept valid token (8ms)

Evidence Types by Change Type

Change Type	Required Evidence	Tool/Method
Logic/algorithm	Test output showing pass	bun test, pytest, go test
File creation	Grep verification or ls output	grep -r "pattern" . or ls -la path/
UI/styling	Screenshot or video	Browser DevTools screenshot
Configuration	Build logs showing success	npm run build, cargo build
Deployment	CI link or deployment logs	GitHub Actions URL, kubectl logs
API changes	API test output or curl result	curl -X POST ...
Data migration	Row count or sample query	SELECT COUNT(*) FROM ...
Performance fix	Benchmark comparison (before/after)	hyperfine, go test -bench

Enforcement Mechanism

Tasks Integration

When marking a todo as completed:

1. BEFORE changing status to completed, gather fresh evidence
2. IN THE SAME MESSAGE that marks it complete, show the evidence
3. NEVER mark complete in one message, then show evidence later

Violation Pattern:

Message 1: "Fixed the validator. Marking todo complete."
Message 2: "Here's the test output..."

Correct Pattern:

Message 1:
"Fixed the validator. Test output:
✓ should validate email (5ms)
✓ should reject invalid format (3ms)

Marking todo complete."

Rationalization Detection

Common rationalizations and their counters:

Rationalization	Counter
"It's a trivial change"	Trivial = fast to verify, not skip
"I tested this before"	Code changed since then, verify again
"Same pattern as working code"	Different context = different bugs
"Just fixing a typo"	Typos can break builds, verify
"Only changed comments"	Comments can break doc generation
"Can't test without production data"	Use test fixtures or staging environment

Examples

Example 1: React Component Fix (TypeScript)

Scenario: Fixed useState initialization bug

Wrong Completion:

Fixed the counter initialization bug. Should be good now!

Correct Completion:

Fixed the counter initialization bug in Counter.tsx line 8:

git diff:
-  const [count, setCount] = useState();
+  const [count, setCount] = useState<number>(0);

Test output:
 PASS  src/Counter.test.tsx
   Counter component
     ✓ renders with initial value 0 (23ms)
     ✓ increments on button click (15ms)

Build check:
✓ Type checking passed (1.2s)
✓ No lint errors

Example 2: Python API Endpoint (FastAPI)

Scenario: Fixed validation error in POST /users

Wrong Completion:

Added email validation to the users endpoint. Tested locally, works fine.

Correct Completion:

Added email validation to the users endpoint in api/users.py line 45:

git diff:
 @app.post("/users")
 def create_user(user: UserCreate):
+    if not re.match(r"[^@]+@[^@]+\.[^@]+", user.email):
+        raise HTTPException(400, "Invalid email format")
     return db.create_user(user)

Test output:
test_create_user.py::test_valid_email PASSED
test_create_user.py::test_invalid_email_rejected PASSED
test_create_user.py::test_missing_at_sign PASSED

Manual curl test:
$ curl -X POST http://localhost:8000/users -d '{"email":"invalid"}'
{"detail":"Invalid email format"}

Example 3: Go Configuration Change

Scenario: Updated Docker build configuration

Wrong Completion:

Updated the Dockerfile to use Go 1.22. Build should work now.

Correct Completion:

Updated the Dockerfile to use Go 1.22:

git diff:
-FROM golang:1.21-alpine
+FROM golang:1.22-alpine

Build verification:
$ docker build -t myapp:test .
[+] Building 45.3s (12/12) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 234B
 => [1/6] FROM golang:1.22-alpine
 => [2/6] WORKDIR /app
 => [3/6] COPY go.mod go.sum ./
 => [4/6] RUN go mod download
 => [5/6] COPY . .
 => [6/6] RUN go build -o /app/server
 => exporting to image
 => => writing image sha256:abc123...

Run verification:
$ docker run myapp:test --version
v1.0.0 (go1.22.0)

Integration with Other Skills

• test-driven-development: TDD provides the tests you'll use as verification evidence
• systematic-debugging: Debug process ends with fix verification (this skill)
• agent-coordination-discipline: Agents must return verification evidence, not just claims
• quality-gates: Quality gate checks are verification evidence types

Quick Reference

Before marking ANY task complete:

1. ✅ Run relevant tests → capture output
2. ✅ Check file changes → show git diff or grep
3. ✅ Verify build → show build logs
4. ✅ For UI changes → take screenshot
5. ✅ For deployments → link CI run
6. ✅ Show evidence in completion message
7. ✅ Only then mark todo as completed

Remember: If you can't show fresh evidence, the task isn't complete yet.