verify-test

What this skill does

# Verify Test Skill

Detect code changes, compare against `test-plan.md`, and update both the test plan and test files to stay in sync.

---

## When to Use

Use `/verify-test` when:
- You just ran `/developer` and made changes to features
- You manually edited source code and need tests updated
- You want to ensure `test-plan.md` reflects current behavior
- You need to keep test files in sync with changed source code

Do NOT use when:
- You want to generate tests from scratch → use `/generate-test`
- You want to run existing tests → use `/run-test-all` or `/run-test-phase`
- No changes have been made since last test generation

---

## How It Works

```
/verify-test [scope]
      |
      v
+----------------------------------------------------------+
|  STEP 1: Detect changes                                   |
|  - Read changes.json (if exists)                          |
|  - Run git diff for modified files                        |
|  - Identify affected features                             |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 2: Read context                                     |
|  - test-plan.md (current test scenarios)                  |
|  - vitest-best-practices.md (testing rules)               |
|  - backend-plan.md (schema, RLS context)                  |
|  - Existing test files for affected features              |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 3: Analyze divergence                               |
|  - Compare changed source vs test-plan.md                 |
|  - Identify: new behavior, removed behavior, changed      |
|    behavior, new features without tests                   |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 4: Update test-plan.md                              |
|  - Add new scenarios for new behavior                     |
|  - Update existing scenarios for changed behavior         |
|  - Mark removed scenarios as deprecated                   |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 5: Spawn qa-specialist agents in PARALLEL           |
|  - One agent per affected feature                         |
|  - Each agent EDITS existing test files                   |
|  - Creates NEW test files only for new features           |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 6: Report changes                                   |
|  - List all modified test files                           |
|  - List all test-plan.md updates                          |
|  - Suggest running /run-test-all to validate              |
+----------------------------------------------------------+
```

---

## Step 1: Detect Changes

### 1.1 Read changes.json (if exists)

```
Glob: **/changes.json
Read: [found path]
```

Extract from changes.json:
- **Recent batches** — look at batches with `status: "completed"` or `"in_progress"`
- **Affected files** — collect all `affected_files` and `output` arrays
- **Change types** — `bug_fix`, `enhancement`, `refactor`, `new_feature`

### 1.2 Run git diff

```bash
git diff --name-only HEAD~5
```

Collect modified files. Filter to source files only:
- `src/features/**/*.ts` / `*.tsx`
- `supabase/**/*.sql`
- `src/lib/**/*.ts`

Ignore test files themselves — we are updating those, not reading changes from them.

### 1.3 Identify affected features

Map changed files to features:

```
src/features/auth/api/auth-queries.ts  → feature: auth
src/features/orders/types/order.ts     → feature: orders
supabase/migrations/20240101_add_col.sql → feature: (parse from migration)
```

Build `{affected_features}` list.

### 1.4 Accept scope override

If the user provides a scope:
```
/verify-test auth        → Only verify auth feature tests
/verify-test all         → Verify all features (re-scan everything)
```

Extract scope directly. **Do NOT ask questions — proceed to Step 2.**

### 1.5 No argument and no changes.json

If no argument provided AND no changes.json exists, use git diff:

```bash
git diff --name-only HEAD~5
```

If git diff also shows no changes:
> No changes detected. Nothing to verify.
> Make changes first with `/developer`, or specify a feature: `/verify-test auth`

**STOP.**

If git diff shows changes, use those as the affected files.

### 1.6 Report detected changes

```markdown
### Detected Changes

| Source | Files Changed |
|--------|--------------|
| changes.json | {count} files across {batch_count} batches |
| git diff | {count} modified files |
| **Affected Features** | **{feature_list}** |
```

---

## Step 2: Read Context (MANDATORY)

### 2.1 Read test-plan.md

```
Glob: **/test-plan.md OR **/test.plan.md
Read: [found path]
```

Extract current test scenarios for the affected features.

**If test-plan.md does NOT exist:**
> `test-plan.md` not found. Cannot compare changes. Use `/generate-test` to create tests from scratch.

**STOP. Do NOT proceed.**

### 2.2 Read vitest best practices

```
Read: references/vitest-best-practices.md
```

### 2.3 Read backend context

```
Glob: **/backend-plan.md
Read: [found path]
```

### 2.4 Read changed source files

For each file in `{affected_files}`, read the current version:

```
Read: src/features/{feature}/api/{file}.ts
Read: src/features/{feature}/types/{file}.ts
Read: src/features/{feature}/hooks/{file}.ts
```

### 2.5 Read existing test files for affected features

```
Glob: tests/features/{feature}/**/*.test.ts
Glob: tests/rls/{feature}*.test.ts
Glob: tests/constraints/{feature}*.test.ts
Glob: supabase/**/{feature}*.test.ts
```

Read each existing test file to understand current test coverage.

---

## Step 3: Analyze Divergence

Compare the changed source code against test-plan.md to identify:

### 3.1 Change categories

| Category | Description | Action |
|----------|-------------|--------|
| **New behavior** | New functions, endpoints, or columns added | Add scenarios to test-plan.md + generate new tests |
| **Changed behavior** | Existing logic modified (different validation, new fields) | Update scenarios in test-plan.md + edit existing tests |
| **Removed behavior** | Functions or fields deleted | Mark as deprecated in test-plan.md + remove related tests |
| **Schema changes** | New columns, changed constraints, new RLS policies | Update constraint/RLS tests |
| **New feature** | Entirely new feature directory added | Add new section to test-plan.md + generate full test suite |

### 3.2 Build change manifest

For each affected feature, create a change manifest:

```
Feature: auth
Changes:
  - ADDED: password reset function (src/features/auth/api/auth-queries.ts:45)
  - CHANGED: login validation now checks email format (src/features/auth/api/auth-queries.ts:12)
  - SCHEMA: added reset_token column to profiles (supabase/migrations/...)
Test Impact:
  - NEW: test password reset CRUD operations
  - UPDATE: update login test to include email format validation
  - NEW: test reset_token column constraints
```

---

## Step 4: Update test-plan.md

### 4.1 Determine test-plan.md edits

Based on the change manifest, determine what needs updating in test-plan.md:

- **New scenarios** → Add under the relevant feature/phase section
- **Changed scenarios** → Edit the existing scenario description and acceptance criteria
- **Removed scenarios** → Remove or mark as deprecated
- **New features** → Add an entirely new section

### 4.2 Edit test-plan.md

Use the Edit tool to make targeted changes to test-plan.md. **Do NOT rewrite the entire file.**

For each change:

```
Edit: [test-plan.md path]
  old_string: [existing scenario text]
  new_string: [updated