/validate
Self-validating loop that spawns parallel verification agents until pass criteria are met.
An autonomous validation loop. Given a task and pass criteria, it spawns parallel verification agents, collects findings, evaluates pass/fail, and iterates until converged.
Trigger phrases#
/validate, validate this, keep checking until done, loop until confident,
self-validate, or when you want iterative verification of any artifact: a spec,
implementation plan, code analysis, or integration design.
Do NOT use for: one-shot reviews (use /review) or simple questions.
What it does#
/validate [description of what to validate]
You provide:
- What to validate: an artifact, plan, analysis, or work product
- Pass criteria: explicit criteria, or "until you're confident"
- Source material: files to read and verify against
If you do not provide explicit pass criteria, /validate derives them from the
task type:
- Spec/analysis verification: zero new findings, zero disputes, zero line drift
- Implementation plans: all steps feasible, no missing dependencies, no conflicts
- Integration work: all behaviors accounted for, no regressions, no gaps
- Code analysis: all claims verified against source, no contradictions
The validation loop#
Phase 0: Setup#
Creates a session directory at Docs/_working/sessions/validate-<topic>/ and
initializes loop-state.json to track iteration history.
Phase 1: Agent allocation#
Decides how many agents to spawn (2–5 per iteration) and what each agent verifies:
| Artifact type | Agent strategy |
|---|---|
| Spec/analysis | Split claims into groups, verify each in parallel |
| Integration plan | One agent per system being integrated |
| Code analysis | One agent per source file or function group |
| General | Divide by aspect (correctness, completeness, consistency) |
Phase 2: Spawn and collect#
All agents run in parallel. Each agent gets a specific verification scope, the source material to read, and a finding ID range to prevent collisions.
Phase 3: Evaluate#
Counts across agent results:
- New findings: previously undiscovered issues or gaps
- Disputes: contradictions of prior iteration's confirmed claims
- Corrections: minor adjustments to prior claims
- Drift: cited references that no longer match
If all pass criteria are met: loop terminates with PASS. If any criterion fails: another iteration begins with updated focus areas.
Phase 4: Iterate or terminate#
Each subsequent iteration prioritizes verifying the previous iteration's findings and uses fewer agents as scope narrows. The loop terminates when:
- All pass criteria are satisfied (PASS)
- 3+ consecutive iterations produce only marginal or out-of-scope findings (CONDITIONAL PASS)
- 7 iterations complete without convergence (hard cap. CONDITIONAL PASS with explanation)
Typical convergence#
- Iteration 1: High finding count (initial broad scan)
- Iteration 2: Moderate (verification and new areas)
- Iteration 3: Low (targeted verification)
- Iteration 4+: Near-zero or out-of-scope only
If iteration 1 produces more than 20 findings, expect 3–5 iterations total. If iteration 1 produces fewer than 10, expect 2–3 iterations.
Final report#
## Validation Complete
**Status**: PASS | CONDITIONAL PASS
**Iterations**: N
**Total findings**: X
**Disputes raised/resolved**: Y/Y
### Iteration History
| Version | Findings | Disputes | Status |
### Coverage
[What was verified and to what depth]
### Remaining Gaps (if CONDITIONAL PASS)
[Out-of-scope or marginal items not resolved]
When to use /validate#
/validate is most useful for:
- Verifying that an implementation plan covers all edge cases before starting code
- Checking a spec against the actual source code for accuracy
- Confirming an integration design accounts for all system interactions
- Any situation where a single review pass might miss something and you want independent parallel perspectives
For a single pass code review before VCS submission, use /review instead.