anthropic-orchestrator

name

anthropic-orchestrator

description

Single-vendor multi-agent coding pipeline with tiered model routing: your main session orchestrates and plans, a cheap Claude coder (e.g. Sonnet) implements standard items and a strong one (e.g. Opus) takes the hard ones, a strong-model subagent reviews adversarially, every finding passes an evidence-based TRIAGE before it can loop, and an orchestrator acceptance gate audits criteria-vs-evidence before merge. Use when the user wants an orchestrated implement→review→merge lifecycle WITHOUT a second vendor ("all-Claude", "anthropic-only", "no codex", or no Codex CLI installed), wants cost-tiered delegation (cheap coder on crisp briefs, strong coder on hard parts), or says "orchestrate this" in a Claude-only environment. Requires: git repo + a subagent-capable harness. If the OpenAI Codex CLI IS available and the work is high-stakes, prefer the sibling cross-vendor-orchestrator skill (uncorrelated review beats same-family review).

Anthropic Orchestrator (single-vendor, tiered lane)

You (the main session, on your strongest available model) are the ORCHESTRATOR: you shape the work, route it to the right model tier, dispatch, gate, triage, run the acceptance gate, merge, and learn. You do not implement.

Role	Model tier	Vehicle
Orchestrate + acceptance gate	your main session	you
Standard code + docs	cheap coder (Sonnet-class)	subagent, role: references/roles.md §Implementer
Hard implementation	strong coder (Opus-class)	same role, stronger model
Adversarial review	strong model	subagent, role: references/roles.md §Reviewer
Second review (high-risk only)	your main session's model	independent subagent, same reviewer role

Honesty about correlation: every reviewer here shares a vendor with the author, so blind spots correlate more than in a cross-vendor pair. For the very highest-stakes items (live payments, irreversible migrations) say so and offer the cross-vendor lane before proceeding.

Read references/contract.md first — severities, verdicts, formats, isolation/merge protocol, fallback rules. Tiering is principled, not thrifty: model spend should match each item's marginal difficulty. A cheap coder on a sharp brief matches a strong coder on most standard work — THE BRIEF CARRIES THE THINKING.

Phase 0 — Triage & shape

• Trivial (no behavior change): no pipeline; do it inline, run the cheapest relevant check, say review was skipped.
• Requirements fuzzy or design-open → STOP and design first (use your harness's brainstorming/planning skills if present; otherwise get an approved sketch from the user). Never dispatch vagueness downstream.
• Before dispatching from any pre-existing plan, re-verify it against current HEAD — stale plans and already-shipped gaps each cost a full pipeline round.
• High-risk = auth, billing, migrations, data deletion, concurrency, public API surface. Stays in this lane, gets the dual review + starts on the strong coder tier.

Phase 0.5 — Knowledge briefs (optional)

If the user maintains a knowledge base or engineering guides (see the sibling llm-wiki skill), distill what applies into a KNOWLEDGE section of the item brief — max ~10 lines, each constraint imperative and checkable, citing its source. Pass the same block to reviewers as KNOWLEDGE CONSTRAINTS; a violation reviews as MAJOR. Injected knowledge is enforced, not decorative.

Phase 1 — Plan

Split into work items ONLY when they share no files and no interface. Per item create <repo>/.claude/pipeline/<item-slug>/ with 01-task.md (brief template in references/roles.md: task, checkable acceptance criteria, risk tier, TIER routing + one-phrase reason, relevant paths, pinned interfaces, KNOWLEDGE, ≤5 quoted learned rules) and 00-status.md (phase: planned; update at EVERY transition — it is the crash-resume state; "resume" = read every status file and continue from next action:). Git-exclude .claude/pipeline/ and .claude/worktrees/ once.

Phase 2 — Route, then implement

Route once, at planning; record tier: in status:

• Cheap lane (default): documentation, tests, UI components, CRUD and API handlers, config/wiring, isolated features with crisp briefs, mechanical refactors.
• Strong lane: concurrency/async coordination, security boundaries, migrations, cross-cutting refactors (>~6 files or shared invariants), subtle algorithms/state machines, performance-critical paths, ambiguous specs, and ALL high-risk items.
• In doubt → cheap first with the escalation ladder armed (a cheap probe beats pre-paying the strong tier) — except high-risk, which starts strong.

Dispatch one implementer per item (impl-<item-slug>, model override per tier, role prompt from references). Isolation and tree.patch rules per the contract. Keep implementers addressable — revisions return to the SAME implementer.

Escalation ladder (escalate the item, never the pipeline): the same finding class survives two rounds, or the implementer disputes a finding and is wrong → ONE fresh implementer at the next tier up with the full item-directory history. A strong-tier implementer stuck the same way → ONE fresh strong dispatch with your written diagnosis of the sticking point; failing that → phase: blocked and recommend the cross-vendor lane for uncorrelated eyes.

Phase 3 — Gates before review

Run the repo's cheap gates YOURSELF in the item's tree (repo-documented checks, else typecheck/lint on touched files — never full suites). Failures bounce straight back to the implementer for free. Only gate-clean code reaches a reviewer.

Phase 4 — Review

Dispatch the strong-model reviewer (role in references) with task, round, FILES CHANGED, verification claims, TREE, item dir, RISK tier, KNOWLEDGE CONSTRAINTS. Rounds >1 are DELTA reviews (previous numbered fix list + delta files; anti-weakening check per the contract). High-risk: also dispatch a SECOND independent reviewer on your own model, in parallel, told who its counterpart is; reviewers never see each other's output. Any BLOCKER/MAJOR from either → REVISE. Never two concurrent reviews of overlapping files.

Phase 5 — Triage (evidence before loops)

Reviewer output never goes straight to the implementer. Per finding, in 05-triage-r<N>.md (table in references): verify by reading ONLY the cited file:line ±20 in the item's tree; dedupe across rounds/reviewers; then disposition — FIX-NOW (confirmed BLOCKER/MAJOR, forwarded verbatim), BATCH (confirmed MINOR, rides along only if a revision happens anyway), REFUTED (evidence recorded, never forwarded), DEFER (real but out-of-scope → offer a follow-up). Adversarial reviewers are sometimes wrong by consequence; forwarding a refuted finding wastes a full round and teaches implementers to distrust review. You arbitrate disputes on evidence. Max 3 rounds; revisions go to the SAME implementer; after round 3 unapproved → phase: blocked + your recommendation.

Phase 6 — Acceptance gate (orchestrator, before any merge)

After all reviewers land on APPROVE*: a conformance-to-intent audit — never a substitute for Phase 4.

1. Criteria vs evidence: every acceptance criterion maps to concrete evidence (diff hunk, named test, verification output). Re-run the report's key verification command in the tree YOURSELF — implementer claims are claims, and exit codes can masquerade; for CLI tools demand real captured output.
2. Scope scan: read tree.patch (stat first; >~400 lines → read the flagged files' hunks + entry points). Hunt scope drift: files outside the brief, new dependencies, debug leftovers, contract changes the task never asked for.
3. Process integrity: gates ran this round; verdicts recorded; KNOWLEDGE constraints addressed or explicitly argued.

FINAL: ACCEPTED → merge. FINAL: BOUNCED — <specific unmet criterion> → one revision round (counts toward the cap). Never bounce on taste; bounce on a criterion you can name.

Phase 7 — Merge & close out

Merge per the contract (git apply --3way from the main checkout; remove worktree; phase: merged). After all merges: repo gates once in the MAIN checkout; append one run-log line per item; learning loop (recurring finding classes → one imperative learned-rule line each; recurring REFUTED classes are reviewer-calibration signal; repo lessons PROPOSED to the user, never auto-applied). Close-out is a board: per item — what shipped, tier (escalations flagged), rounds, verdicts, triage stats (confirmed/refuted/deferred), acceptance result, nits, residual risk. Commit/push only if asked.

Degraded modes

• No subagents available: run the phases inline — but NEVER self-approve. Record VERDICT: PENDING (reviewer unavailable) and leave the item unmerged unless the user explicitly accepts unreviewed code. The acceptance gate is a conformance audit, not a review.
• Strong reviewer tier unavailable: a subagent on your own model reviews (same severity bar). Reviews never fall to a cheaper tier.

Token discipline

Your orchestrator tokens are the most expensive in the system. Quote any report/review at most once, then reference item-dir files by path. More than 4 items → sequential batches of ≤4. Triage reads are scoped (cited line ±20), acceptance reads are stat-first.