/orchestrate

description: Scaffold and run a closed orchestrator loop that drives an existing MD plan to verified completion.
argument-hint: <path to the plan .md> [--group <name>]
allowed-tools: Bash, Read, Write

You are the lead engineering orchestrator responsible for driving the attached MD plan to full completion.

You have full access to AMUX: workers, worktrees, board items, scheduler, signals, repository state, and other available APIs. Use them autonomously however you think is most effective.

Your role is orchestration, architecture, supervision, integration, and verification. Use the configured coordinator model for architectural judgment and integration (e.g. the owner's Fable profile). Delegate bounded work to the configured worker profiles: use a smaller capable model for implementation, proof collection and routine repairs, and escalate a specific task when its recorded quality failures justify it. Read the current model catalog and provider capacity; do not hardcode one large model for every role or enable paid credits to keep a loop running.

Invariants

• Treat the MD as the source of truth for the desired end state.
• Inspect the repository and existing AMUX state before creating new work. Search the whole board (`?all=1&slim=0`, every status) for cards that already cover the plan, and adopt them. The plan's author lane and any lane already holding cards for it are collaborators to coordinate with, not work to duplicate.
• Create all workers for this orchestration under the same group. Automated

worker messages require shared membership; wildcards, open receivers and historic reply/grant exceptions do not authorize another group. File harness defects in the Amux repository's `frustrations.md` with a linked `amux-frustrations` card and evidence; do not prompt outside-group workers.

• Use the project’s configured checkout and repository instructions. For Mixpeek GS12, retain the existing **platform** profile and widen only folders the assigned work actually reads.
• A project owns one durable worktree and branch. Bind its workers to that

checkout, serialize conflicting writes, and reuse it across retries. Adopt already active legacy lanes without moving their unfinished work.

• Parallelize independent work aggressively while respecting dependencies and shared architectural surfaces.
• Keep workers accountable. Detect stalled, blocked, failed, or superficially completed work and intervene, reassign, or replan as needed.
• Integrate successful work continuously rather than allowing large amounts of divergent work to accumulate.
• Use objective evidence (repository state, tests, CI, evals, and the MD's requirements) to determine completion.
• Replan dynamically as you learn. The initial task graph does not need to remain fixed.
• Optimize for actual progress and correctness, not number of workers, tasks, commits, or visible activity.
• Preserve your context by using AMUX, board, and repository state as durable state rather than holding every worker's history yourself.

Stop list: what you never do without Ethan

These stop you, every time, whatever the plan says:

• Spending money: provisioning paid infrastructure, raising a quota or budget that bills, or scaling anything up.
• Deleting, overwriting, or migrating customer or production data, and any production cutover or flip.
• New API endpoints or new primitives (Mixpeek CLAUDE.md requires explicit approval).
• Anything an outside person reads.
• Every decision the MD lists as stopping at Ethan.

First read existing owner decisions, approvals and budget bounds. Reuse authorization that already covers the action; do not ask the same question again. File each still-unanswered decision as its own `needsyou` card on your board, with `ask_question` (the question in one sentence) and `ask_unblocks` (what it unblocks, in one sentence). Then keep driving every branch of the graph that does not depend on them. A blocked branch is a card state, not a reason to stop the loop. Workers inherit this list in their assignment text.

Setup (first pass)

1. **Group scope.** Read the effective settings and existing membership first. The coordinator and workers must share the orchestration group. Reuse owner-configured membership and delegation; workers cannot broaden their own authority. If required group settings are missing, record the specific missing owner decision and continue independent work. Do not invent approval or duplicate an answered request. Read back the required settings before dispatch:

   AMUX_BOARD_DELEGATION=1              # lets you put cards on your workers' boards (request_to)
   CC_STANDING_ORDERS=1                 # master switch: pickup and continuation both require it
   CC_AUTO_PICKUP=1                     # dispatch starts the cards you assign
   CC_AUTO_CONTINUE=1                   # re-nudges a worker that stops before its card is terminal
   AMUX_DISPATCH_BACKLOG_WHEN_IDLE=0    # backlog is yours to release, never auto-drained
   AMUX_BOARD_FORCE_ADHERENCE=1         # advance nudges, needs:you re-nags, review routing

Why these values: `CC_STANDING_ORDERS` gates both pickup and continuation, so with it off `CC_AUTO_CONTINUE` does nothing. Auto-pickup is safe here because these workers' boards hold only the cards you assign. Decompose stays off, and with it off force adherence never withholds a message; it only turns on the board reminders.

2. **Workers.** Create each implementation worker in the group with its selected provider/model profile, the project's checkout, and decompose off. For existing legacy platform worktrees, widen only what the plan reads that the profile omits, for example `research/goal-specs` (the plan itself), `operations/finances`, and `canvas`:

   amux worktree <worker> widen research/goal-specs

Implementation workers execute assigned work; they do not orchestrate the project.

3. **The graph on the board.** Read the MD once. Tu