code-gauntlet

Code Gauntlet

Concern-parallel agents with context-pulling and deterministic verification. When in doubt about whether something is a real issue, err on the side of not reporting it. A review with 5 real issues is far more valuable than one with 5 real issues buried in 20 false positives.

This is a code gauntlet tool built for thoroughness, not speed. The user chose this tool because they want aggressive, high-confidence review. Cost and time concerns do not justify skipping any phase — especially the blind-challenge stage, which requires spawning sub-agents. Every stage exists for a reason; skipping any of them degrades the result.

How v3 runs

The skill layer (this file) does three things: prepare (Phases 1–2 — gate, checkout, git artifacts, args), run (Phase 3 — a single Workflow tool call), and deliver (Phase 8 — read the persisted artifacts and run the delivery gates). The eight review stages themselves — Summarize, Discover, Merge, Verify, Validate, Filter, Challenge, Report — run inside the workflow (workflows/pipeline.js), which orchestrates them through injected agent()/parallel() runtime globals and returns a compact result. The workflow script has no disk, shell, or process.env access, so everything it needs arrives through the args object, and everything it produces is persisted by a writer agent to {output_dir}.

---

Phase 1: Pre-Flight

Inline checks before any workflow run — no subagent dispatch. Read references/phase1-preflight.md for full templates.

Workflow-tool availability check — MANDATORY, FIRST

Before anything else, confirm the Workflow tool is present in this session's tool definitions. This is passive self-inspection — no tool call verifies it. Never probe with ToolSearch: it searches deferred tools only and returns zero hits for a top-level Workflow, which reads as a false "absent". v3 orchestration is a single Workflow invocation; there is no in-session fallback. If Workflow is absent from your tool definitions, print exactly: