dev-leadlisted

# Dev lead: dispatch → implement → adversarial rounds → merge gate This is the orchestration layer over the eight family skills: `{claude,codex,agy,opencode}-implement` and `{claude,codex,agy,opencode}-adversarial-review`. It adds no new mechanics — it decides who does what, how many rounds, and when to stop. Read the underlying skill before invoking it; every operational gotcha (sandbox allow-lists, workspace traps, silent-death modes, status commands that lie) lives there and is not repeated here. The lead role itself is portable: all six CLIs can read the same skills directory (symlink the others' skills paths to Claude's), and the `claude-implement`/`claude-adversarial-review` skills supply the missing direction — Claude as a worker for a codex or agy lead. A codex-led run has been completed end-to-end (the interactive codex CLI as lead, briefed by a pilot doc, ran capability probes first and delivered through the merge gate). The distinction that makes this work: **capability is a property of the RUNTIME, not the brand** — a companion's restricted sandbox may be unable to commit in a worktree while the same vendor's interactive CLI under an approved elevated runner passes the gate. What does not port automatically is host-specific tooling (harness-tracked background tasks, subagent APIs) — a foreign lead substitutes its own process management. **Host capability gate — check BEFORE accepting the lead role.** The lead must be able to run the suite and execute mutations