verify

Files (3)

• SKILL.md
• check-types.md
• debug-protocol.md

SKILL.md (first lines)

# Verify

Run after any significant output to catch what was missed. The goal is to prevent the class of error where work appears complete but isn't — unfetched data, stale counts, broken assumptions, missing files.

## Input

Target to verify: `$ARGUMENTS`

If no arguments, verify the most recent significant output or pipeline step.

## Process

### Step 1: Identify What to Verify

Determine the verification type from context:

| Type | Trigger | What to Check |
|------|---------|--------------|
| **Data pipeline** | After running a pipeline (refresh, ETL, etc.) | Row counts, coverage rates, missing fields, stale references |
| **Implementation** | After implementing from a plan | All plan items addressed, tests pass, no regressions |
| **Analysis** | After producing analysis/reports | Claims supported by data, no unfetched sources, numbers consistent |
| **File output** | After generating files | Files exist, non-empty, correct format, no orphan references |

### Step 2: Run Checks

Read the relevant files and run checks appropriate to the type. See `~/.claude/skills/verify/check-types.md` for the four composable check categories (data, completeness, consistency, assumption). A single verification usually draws from multiple categories — e.g., a data pipeline verification runs data + completeness + consistency.

### Step 3: Report

Format findings as:

```
VERIFICATION — [target]

PASSED:
- [check]: [result]

FAILED:
- [check]: [what's wrong] → [suggested fix]

WARNINGS:
- [check]: [not broken but suspicious]

COVERAGE: [X/Y checks passed]
```

If everything passes, say so concisely. Don't pad the report.

### Step 4: When Verification Fails — Debug Protocol

If Step 3 reports FAILED items, do not jump to fixing. See `~/.claude/skills/verify/debug-protocol.md` for the full 4-phase protocol.

## Red Flag Language (from Superpowers)
If you catch yourself or a subagent using any of these phrases, STOP and re-verify:
- "Done!", "should work", "probably fine", "seems to", "I believe this handles"
- "Great!", "Perfect!" (sycophantic completion signals)
These indicate a completion claim without fresh evidence. Run the actual checks.

## Three-Fix Escalation Rule (from Superpowers)
If a verification failure has been "fixed" 3 times and still fails, STOP. Don't try a fourth fix. The architecture is probably wrong. Escalate to the user: "This has failed 3 fixes. The approach itself may need rethinking."

## Gotchas
- The most dangerous failures are silent ones — things that LOOK complete but aren't. Prioritize checking those.
- Don't just verify what was done. Verify what SHOULD have been done but might have been skipped.
- When verifying data pipelines, always check the enrichment chain: raw → enriched → categorized → indexed. A break at any stage propagates silently.
- Stale counts in COMP files are the most common consistency failure after batch operations.
- After writing to MEMORY.md or project docs, verify the information is actually findable by future agent sessions (discoverability check).

From griffinhilly/claude-code-synthesis, MIT.

More from griffinhilly/claude-code-synthesis