---
name: self-validation-loop
description: |
  After generating code, automatically spawn validator agents in parallel
  (test-generator + code-reviewer + security-auditor) to catch issues
  before the user runs the code. If any validator finds a problem, the
  loop iterates: regenerate → revalidate → up to N attempts. Stops only
  when all validators sign off OR max attempts reached.

  Use when:
  - code-generator just produced new code
  - large refactor was just applied
  - migration was just written
  - security-sensitive code path was touched (auth, crypto, payments)
  - code was generated without tests already in scope
---

# Self-Validation Loop — Trust, but Verify (Automatically)

The fastest way to ship broken code is to skip validation. The fastest way
to ship correct code is to validate so consistently it becomes muscle memory.
This skill makes that muscle memory automatic.

## Trigger Conditions

```
ALWAYS trigger after:
  - code-generator agent completes
  - migration-generator agent completes
  - terraform-generator agent completes
  - refactor-master applies a 🟠/🔴 tier refactor
  - Edits to files matching: auth/, payments/, crypto/, security/

OPTIONALLY trigger after:
  - Any Edit/Write that exceeds 50 LOC delta
  - Any commit prep step

DON'T trigger for:
  - Single-line typo fixes
  - Documentation-only changes
  - Test file changes (tests validate code, not vice versa)
  - Dependencies-only changes (lockfile bumps, etc.)
```

## Validator Panel

```
DEFAULT (3 validators in parallel):
  - test-generator       → does coverage / does test suite pass?
  - code-reviewer        → quality, idioms, pitfalls?
  - security-auditor     → injection? auth bypass? secret leak?

EXTENDED (add for sensitive code):
  - performance-analyzer → hot path concerns?
  - db-doctor            → if SQL touched
  - accessibility-reviewer → if UI touched
```

## Loop Protocol

```
Loop (max 3 iterations):

  1. SUBJECT under validation
     Capture: files changed, diff range, test command(s) for this stack

  2. DISPATCH validators in parallel
     Each validator returns:
       VERDICT: PASS | FAIL | NEEDS_INFO
       FINDINGS: <list, severity-tagged>
       BLOCKING: <yes/no>

  3. AGGREGATE
     - All PASS → exit loop, mark VALIDATED
     - Any FAIL with BLOCKING → enter remediation
     - Only NEEDS_INFO / non-blocking → user reviews

  4. REMEDIATE (if FAIL)
     - Group findings by file
     - Re-invoke the appropriate generator with the failure context as input:
         "Previous attempt failed validation:
            - <validator>: <finding>
          Generate a corrected version."
     - Apply, re-enter loop

  5. STOP CONDITIONS
     - Validated (all PASS) → DONE
     - Max iterations reached → REPORT what's still failing, defer to user
     - Same finding repeats 2x → STOP, escalate (likely needs human judgment)
```

## Output Format

Per iteration:
```
🔄 SELF-VALIDATION — pass <n>/3
  test-generator:    PASS  (coverage 87%, all tests green)
  code-reviewer:     FAIL  (1 blocking: unhandled error path in handler.ts:42)
  security-auditor:  PASS

  REMEDIATION: regenerating handler.ts with explicit error handling…
```

Final:
```
✅ VALIDATED in <n> passes
   Files: <list>
   Tests: <count> added/updated
   Reviewers' notes (non-blocking):
     - <note>
     - <note>
```

Or:
```
⚠️ VALIDATION INCOMPLETE after 3 passes
   Outstanding issues:
     - <validator>: <finding>
   Recommendation: human review before merging.
```

## Failure Escalation Heuristics

```
If the SAME validator surfaces the SAME finding 2 iterations in a row:
  → escalate to human; auto-loop is not converging.

If two DIFFERENT validators block on a CONFLICTING demand:
  (e.g., security-auditor wants strict input rejection, but
   test-generator's coverage tests rely on graceful tolerance)
  → invoke `consensus-voting` skill to resolve.

If validator can't run (env issue, missing deps):
  → skip with NEEDS_INFO, note in output, don't fail the loop.
```

## Anti-Patterns

- Running validators sequentially (always parallel — they're independent)
- Lowering the bar to make tests pass faster ("just delete the failing assert")
- Treating "no findings" as "no issues" (also check coverage went up)
- Looping > 3 times (you're not converging — stop and ask a human)
- Ignoring NEEDS_INFO ("env can't run pytest") — at least flag it
- Validator-on-validator (don't validate the test code with another test agent)

## Integration

- Auto-trigger via PostToolUse hook for code-generator outputs (planned)
- Pairs with `learning-loop` — if the same finding keeps appearing across
  sessions, persist the pattern as a project lesson
- Feeds `release-manager` pre-flight: validated code passes pre-flight faster