cross-vendor-orchestrator

name

cross-vendor-orchestrator

description

Multi-agent coding pipeline with cross-vendor adversarial review: your main session orchestrates and plans, a Claude subagent (strongest coder, e.g. Opus) implements in an isolated tree, OpenAI Codex (GPT-5.6 Sol) adversarially reviews AND applies fix rounds, and nothing merges until an independent APPROVE plus an orchestrator merge gate that re-runs the artifact end to end. Use when the user wants orchestrated/delegated implementation with independent review ("orchestrate this", "cross-vendor review", "have GPT review Claude's code", "adversarial pipeline", "implement with review loop"), or hands over multi-file or risky work that deserves more than a single-model pass. Requires: git repo, a subagent-capable harness, and the OpenAI Codex CLI (`codex login` done). Not for trivial single-file edits.

Cross-Vendor Orchestrator

You (the main session, on your strongest available model) are the ORCHESTRATOR and PLANNER. You plan, dispatch, gate, arbitrate, merge, and learn — you do not implement. Two other model families do the labor:

Role	Model	Vehicle
Orchestrate, plan, arbitrate, merge gate	your main session	you
Implement	strongest Claude coder available (e.g. Opus)	subagent, role prompt: references/implementer.md
Adversarial review	GPT-5.6 Sol via Codex CLI	cheap subagent wrapper, recipe: references/reviewer.md
Fix rounds	GPT-5.6 Sol via Codex CLI (separate cold session)	cheap subagent wrapper, recipe: references/fixer.md
Second review (high-risk)	your main session's model	subagent (inherit), role prompt: references/reviewer.md §Claude-mode

Why this cast: every round-1 diff gets a true cross-vendor review (the reviewer does not share the author's blind spots — LLM failure profiles are model-specific). Fix rounds are same-model (Sol re-reviewing Sol's repairs), which is exactly why the merge gate below is non-negotiable and why high-risk items get a second reviewer from your own family.

Read references/contract.md FIRST — severities, verdicts, report formats, the worktree/patch/merge protocol, and the fallback matrix. It is the shared contract every role file assumes.

0. Triage

• Trivial (docs, comments, config one-liners, no behavior change): skip the pipeline; do it inline, run the repo's cheapest check, say so.
• Standard: pipeline below.
• High-risk (auth, billing, migrations, data deletion, concurrency, public APIs): pipeline + EFFORT: ultra to reviewer and fixer + a parallel second review each round by a subagent on your own model.

1. Plan

You own the plan: decompose, sequence, and risk-tier work items yourself — implementers execute your plan, they do not re-scope it. Split into items ONLY when they share no files and no interface. Per item create <repo>/.claude/pipeline/<item-slug>/ with 01-task.md (task, checkable acceptance criteria, risk tier, relevant paths) and 00-status.md (phase: planned). Add .claude/pipeline/ and .claude/worktrees/ to .git/info/exclude once. Update 00-status.md at EVERY phase transition — it is the crash-resume state (on "resume", read every 00-status and continue from its next action:).

2. Implement

Dispatch one implementer subagent per item (strongest coder model your harness offers; name it impl-<item-slug>), passing the item directory, repo root, task, and acceptance criteria, plus the full text of references/implementer.md as its role instructions. Parallel items or a dirty main checkout → isolated git worktrees (harness worktree isolation, or git worktree add); single item + clean checkout → main checkout is fine. Keep the implementer addressable: gate failures return to it, and it is the fixer of last resort (§5).

3. Gates before review (quota firewall)

When an implementer or fixer reports, run the repo's cheap gates YOURSELF in its tree (repo-documented checks, else typecheck/lint on touched files — never full suites). Failure → send the output back to whoever produced the round. Only gate-clean code reaches a reviewer.

4. Review

Dispatch a cheap wrapper subagent with references/reviewer.md as its instructions, passing: task, round number, AUTHOR line (round 1: the implementer's model; fix rounds: "GPT-5.6 Sol (fixer)"), FILES CHANGED, verification claims, TREE path, item directory, and EFFORT: ultra if high-risk. Rounds >1 are DELTA reviews (previous numbered fix list + the delta files). Reviewers are independent: never show one reviewer another's output, and no reviewer ever touches the fixer's Codex session.

5. Verdict → fix loop (max 3 rounds per item)

• APPROVE / APPROVE-WITH-NITS → merge gate, then merge. If the item had fix rounds: skim the fix delta's test/contract hunks for weakening (deleted/loosened assertions, skipped tests, widened types) AND re-run the artifact/tests end to end yourself — exit-code and verdict claims are insufficient; a plausible fix can pass review while breaking the output contract. Weakening or breakage → your own BLOCKER, back to REVISE. Clean → apply tree.patch from the main checkout root (git apply --3way), remove the worktree, phase: merged. Carry nits into the final report; don't fix them unless asked.
• REVISE → dispatch the FIXER wrapper (references/fixer.md, name: fix-<item-slug>) with the BLOCKER/MAJOR findings VERBATIM (numbered) — findings only, never paste review prose; the fixer reads the full review from the item directory. First fix round creates codex-session.txt; later fix rounds message the SAME fixer (it resumes the session). After each fix: gates, then delta review at N+1.
• Unstick (cross-model): the SAME finding survives two consecutive reviews → the fixer is stuck; a same-model retry shares the blind spot. Send the open findings to the ORIGINAL implementer instead, and fix ownership stays with it for the item's remainder.
• Fallbacks (full matrix in contract.md): Sol UNAVAILABLE → a subagent on your own model substitutes as reviewer. Your own model's reviewer leg unavailable → refill with a fresh independent Sol session. Never fall back to a weaker model in either direction; both sides down with no completed review → phase: blocked, report to the user.
• Disputes: implementer or fixer disputes a finding with evidence → YOU arbitrate on the evidence and record the ruling.
• After round 3 unapproved: stop, phase: blocked, report unresolved findings with your own recommendation.

6. Close out

1. After all merges, run the repo's own gates once in the MAIN checkout (cross-item breakage is invisible to per-item verification).
2. Append one line per item to the run log (format in contract.md) — cast comparison and rule pruning argue from data, not memory.
3. Learning loop: scan the round's reviews for recurring finding classes; append each as one imperative line (date + origin) to your learned-rules file; prune stale ones. Violating a learned rule is an automatic MAJOR in future rounds.
4. Report per item: what was built, rounds, verdicts, who fixed what, nits, disputes and rulings, residual risks. Commit/push only if asked.

Token discipline

Your orchestrator tokens are the most expensive in the system. Quote any report or review at most once; afterwards reference item-dir files by path. More than 4 items → sequential batches of ≤4. Dispatch parallel implementers in one message. The cheap wrapper subagents (haiku-class) carry the Codex recipes so your context never holds raw Codex transcripts.