| 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.
- 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.
- 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.
- 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.
