vc-autoresearch

Output style: Follow process/development-protocols/communication-standards.md, answer-first, plain language, no unexplained jargon, TL;DR on long responses.

Reusable loop primitive. Runs: find gaps → write report → fix → check → repeat.

Used directly for spec/doc/UX hardening. Wired into PVL (plan-validate-fix loop, the fix cycle between writing a plan and approving EXECUTE) and EVL (execute-validate-fix loop, the confirmation run after EXECUTE) as the shared bookkeeping layer.

---

When To Invoke

• Standalone: user says "harden this spec", "fix all lint errors", "improve test coverage"
• PVL: the ORCHESTRATOR invokes it when vc-validate-agent returns a first-pass CONDITIONAL/BLOCKED verdict (validate-fix loops are needed)
• EVL: the ORCHESTRATOR invokes it at the EVL confirmation run, unconditionally after every EXECUTE DONE, before UPDATE PROCESS

Do NOT invoke during RESEARCH or INNOVATE phases.

Who Runs This (Loop Driver)

The ORCHESTRATOR is the loop driver. It executes every bookkeeping step itself:

• Step 0 setup, creates the task folder and the results.tsv tracking file.
• Cycle counter + per-cycle iteration report, writes one report file per loop iteration.
• TSV row, appends a row to results.tsv after each cycle.
• Plateau/cap/regression checks, stops the loop when no progress is made for 3 cycles (HALT_PLATEAU, no improvement after 3 tries), when the hard 10-cycle limit is hit (HALT_CAP), or when a test that was passing now fails (HALT_REGRESSION).

Subagents (vc-validate-agent, vc-tester, vc-plan-agent, vc-execute-agent) are fire-and-forget: they emit a verdict and terminate. They cannot invoke this skill on the orchestrator's behalf, cannot loop themselves, and cannot spawn each other.

If no one runs Step 0, the loop never exists and verdicts silently become "proceed", that failure mode is exactly what this section forbids.