Orchestrate Chorus

Orchestrate Skill

This skill is for an orchestrator (typically an Admin-preset agent) that coordinates other agents and humans across the AI-DLC lifecycle instead of doing all the work itself. The orchestrator decomposes work, hands each piece to a chosen owner, runs independent reviewers as quality gates, and gatekeeps the human-owned approval/verify gates — but never ships on its own.

It complements the other skills rather than replacing them:

• yolo-chorus (<BASE_URL>/skill/yolo-chorus/SKILL.md) — one agent drives the whole pipeline solo. Orchestration is the opposite: many agents, each owning a piece, coordinated by you.
• idea-chorus, proposal-chorus, develop-chorus, review-chorus, quick-dev-chorus — a single stage you execute yourself. Orchestration is the layer above those: you decide who runs each stage.

---

When to use this skill

Use it when more than one agent (or agent + human) will touch the work and someone has to keep them coherent:

• You own a theme / epic / container idea that decomposes into several independent child ideas, and you want to hand each child to a specific worker (the motivating case: a theme owner gives one child to Codex, another to a Claude dev agent, another to a human).
• An approved proposal has a task DAG and you want several developer agents working the unblocked tasks in parallel waves.
• You need an independent adversarial review of someone else's proposal / task / feature before it advances.
• You are the responsible owner and must keep one accountable assignee per idea while work fans out.

Prerequisite: delegating ideas needs idea:admin; delegating tasks needs proposal:write. Run chorus_checkin() first to confirm your permission set.

---

Delegation primitives

Assign an idea — chorus_pm_assign_idea (idea:admin)

Hand a whole idea to a chosen agent or user. Parameters:

Behavior you must understand:

• The assignee is woken and advances from the idea's current stage — it does NOT re-claim. If the idea is open it moves to elaborating; any other status is preserved. The assignee picks up wherever the idea already is (elaboration, ready-for-proposal, etc.).
• Agent targets must hold idea:write (via a preset such as pm_agent/admin_agent, or an explicit permission) or the call is rejected. User targets must be in your company. instanceUuid is rejected for user targets.
• Silent takeover. Reassigning an already-owned idea simply moves ownership to the new assignee — there is one owner at a time, no confirmation prompt. Use this deliberately, not by accident.

Assign a task — chorus_pm_assign_task (proposal:write)

Hand a single task to a developer agent. Parameters: taskUuid, agentUuid (must hold task:write), optional instanceUuid. The task must be open or assigned. The assignee is woken to execute it. Use this to distribute the tasks of an approved proposal.

Derive child ideas and fan them out

The theme-decomposition case, end to end:

1. Read the container/theme idea and its context (chorus_get_idea, chorus_get_documents, chorus_get_comments).
2. For each independent slice, create a child idea with chorus_pm_create_idea (link it back to the parent in the body / via references[]).
3. Assign each child to a distinct owner with chorus_pm_assign_idea — e.g. one child to Codex, one to a Claude dev agent, one to a human. Each child now has its own single owner and advances independently.
4. @mention each assignee and the theme owner so the delegation is visible.

---

Independent review as an adversarial gate

Chorus uses three read-only adversarial reviewers as quality gates. As orchestrator you run them at the three gates and act on the verdict — this is your primary quality lever when you are not writing the code yourself.

Spawn a read-only sub-agent that loads the matching reviewer skill and the target UUID (pass the ideaUuid for code review); if your harness has no sub-agent primitive, run the reviewer's procedure inline yourself. Wait for it with your harness's own waiting mechanism, then read THIS round's VERDICT: comment for the entity under review with chorus_get_comments — posted after your dispatch, not an older round's — before advancing. Each posts exactly one VERDICT: PASS / PASS WITH NOTES / FAIL comment. Verdicts are advisory — they do not auto-approve, auto-verify, or hard-block; you read the BLOCKERs and decide. A FAIL means route the BLOCKERs back for a fix before advancing (for a code-review FAIL, add fix tasks to the approved proposal via quick-dev-chorus and re-run once they are done). The Independent Review section of the core chorus skill (<BASE_URL>/skill/chorus/SKILL.md) is the canonical description of this pattern.

First-principles alignment (a stage-tailored instruction in each reviewer). Every one of the three reviewers also checks, top-down, that the work still serves the original Idea's intent — it resolves the Idea from the entity under review, reads it via the existing chorus_get_idea + chorus_get_elaboration + chorus_get_comments, builds the intent baseline from human-authored content only, and flags scope creep, requirement loss / shrink, or semantic drift. Unauthorized drift is a BLOCKER → FAIL / reject, downgraded to a cited NOTE only when traceable to a human-originated authorization (a human-authored Idea comment, a human-answered elaboration entry, or an explicit human override at the gate) — an agent's own comment never authorizes, so a drifting agent cannot self-clear. As orchestrator, route an alignment FAIL back for a fix like any other BLOCKER, or record the human override at the gate.

---

Choosing a collaboration mode

Pick the lightest mode that fits the shape of the work:

Guidance: start narrow. If a single owner can hold the whole feature in their head, prefer single-owner — coordination overhead is not free. Reach for fan-out only when slices are genuinely independent (separate scope, separable elaboration). Use parallel task waves only after a proposal is approved and its DAG is real; respect dependencies — to_verify does not unblock downstream, only done does.

---