A Claude Code skill that drives N parallel coding tasks to completion through a strict per-task lifecycle: implement → /secure → /review → fix → verify → fix → done.
Full docs: skills/orchestrator/SKILL.md.
Copy into your Claude Code config directory (~/.claude/ for global, or <project>/.claude/ for project-local):
skills/orchestrator/ → ~/.claude/skills/orchestrator/
commands/secure.md → ~/.claude/commands/secure.md
commands/review.md → ~/.claude/commands/review.md
agents/security-reviewer.md → ~/.claude/agents/security-reviewer.md
Or clone this repo and symlink each piece.
Bundled — required for the core loop:
/secure— security review (dispatches to thesecurity-revieweragent, also bundled)/review— general code review (correctness, security, performance, maintainability, test coverage)
Optional — the skill checks for these and degrades gracefully if they're missing, rather than assuming:
/agent-browser— used by frontend verifiers to drive an actual browser. Without it, verifiers fall back to a static diff review and note the reduced coverage explicitly./audit— a UI/accessibility/theming auditor from a separate design-skill library. It is not a general code-quality tool (that's/review, bundled) and depends on sibling skills this repo doesn't include. Only relevant if you already have that library installed.
The orchestrator isn't limited to one model. Per Phase 2 of SKILL.md, it enumerates whatever agent types are actually available in your harness each session and assigns each worker/verifier by role — default, strong-reasoning, fast/cheap, specialized — rather than hardcoding names. Verifiers default to a different model family than the worker that built the task, when the roster has one, since a different model is more likely to catch what the builder rationalized away.
A run with several model families installed might look like this:
● main
○ sonnet Checking server.py diff stats
○ kimi Running full pytest suite
○ opus Adding _note_unresolved_failure to treasury_webhook.py
○ codex (+1) Reading WS5 harness output
Four parallel-safe tasks, four different models — chosen for fit (a hard fix went to the strong-reasoning tier, a full test run went to a fast tier, verification landed on a different family than its worker) not availability of just one vendor.
Getting more than one model family in your roster. By default your harness only exposes whatever's natively configured, which for most people is one vendor. CLIProxyAPI wraps other providers' CLI-based models (Codex, Gemini/Antigravity, Grok, Claude Code) behind an OpenAI/Gemini/Claude-compatible API, so they can be registered as additional agent types your harness dispatches to. Once configured, orchestrator picks them up automatically — Phase 2 discovers the roster live, no changes to this skill needed. Without it, orchestrator still works fine on a single-family roster; it just says so in its plan instead of silently skipping cross-family verification.
MIT — see LICENSE.