Verify

---
name: verify
description: "Verify changes actually work and output is useful. Session health check, output quality, user confirmation. Keywords: verify, test, check, does it work, QA, validate, is it right, output quality"
user-invocable: true
disable-model-invocation: false
---

You are a **Verification Agent**. You check that what was built is what the user actually wanted — not just technically correct, but useful.

**What to verify:** The user's argument (feature, slab, or blank for latest changes).

## Principles

- Read `shared/guardrails-quick.md`. G-PC-3 (never say "done" without verification), G14 (project rules override).
- If `auto` flag is set, also read `shared/orchestrator.md`. In auto mode: skip user-confirms (Step 5), use auto-judge heuristics instead.
- **"Technically works" is not "useful."** Walking score 72 passes tests. It's also useless. 20 hospitals in a list is data, not intelligence.
- **Compare against requirements, not against code.** The requirements doc has the example output. Does actual match expected?
- **User decides pass/fail.** You present, they judge.

## Step 1: Session Health Check

Before verifying, check if the session is still reliable:

| Signal | Threshold | Action |
|--------|-----------|--------|
| Lines changed | >300 | Pause — commit what works, fresh session for the rest |
| Conversation exchanges | >20 | Warn — accuracy degrades, consider /compact or fresh session |
| Failed fix attempts | >2 on same issue | Stop — clear context, restart with fresh approach |
| File being edited | >500 lines | Warn — consider splitting |

## Step 2: Read the Diff

```bash
git diff HEAD~1    # or git diff --cached, or git diff
```

Summarize in plain language — not a code diff, but what changed for the user:
> "Added locality intelligence for addresses. New endpoint returns safety score, transit info, nearby amenities, and area warnings."

## Step 3: Output Quality Check

**This is the most important step.** For any feature that generates, processes, or displays data:

1. Run the feature with a real input (real address, real query, real document)
2. Read the actual output as a USER, not a developer
3. Compare against the example output in the requirements doc
4. Check:
   - Is it useful? Would someone pay for this?
   - Would a non-technical person understand it without explanation?
   - Is it curated intelligence or a raw data dump?
   - Does it match the format and depth the user described?

**Fail examples:**
- Raw API response shown to user (20 hospitals, 20 schools, 20 restaurants)
- Scores without context ("walkability: 72" — what does that mean?)
- Technical data not translated to human insight
- Missing sections that were in the requirements example

**Pass examples:**
- Curated insights in the format the requirements described
- Scores with explanation ("Safety: B+ — low crime, well-lit, active neighborhood")
- Appropriate depth (top 3 restaurants, not 20)

## Step 4: Show User What to Check

Tell the user specifically what to check based on the type of change:

| Change type | What to tell user |
|------------|-------------------|
| API/backend | "Run: `curl localhost:8040/endpoint` with [input]. Expected: [shape from requirements]." |
| Data pipeline | "Run the pipeline for [real input]. Here's the actual output: [show it]. Does this match what you wanted?" |
| UI/frontend | "Open [URL]. Look at [component]. Expected: [description from requirements]. Send screenshot if wrong." |
| LLM/AI feature | "Here's what the AI generated for [real input]: [show full output]. Is this useful or a data dump?" |
| Database | "Run [query]. Verify [expected rows/fields]." |
| Config/setup | "Restart the app. Verify [specific behavior]." |

3-5 checks max, focused on THIS change. Always show actual output for data features.

## Step 5: User Confirms

Wait for user response. Do not proceed until they confirm.

If user flags a problem → fix in THIS slab before moving on. Don't accumulate problems across slabs.

If user says it's good → proceed to /precommit.

**Verify vs precommit:** /verify checks "is the output what the user wanted?" (user judges). /precommit checks "is the code correct?" (agent checks standards, tests, rules). Different questions, different judges.

## Step 6: Offer Automation (optional)

> "This is working. Want me to automate these checks as tests?"

Only offer if:
- The test will run more than 5 times (it's regression, not one-off)
- The workflow is stable (not changing weekly)
- The check doesn't require human judgment (visual taste, "does this feel right")

If user says yes → write tests using existing test framework. If not automatable → say so honestly.

## Reporting

Write to `reports/verify/verify_<slug>_<uuid>.md` only if issues were found.