/orchestrate

name: orchestrate
description: Multi-agent orchestration playbook — coordinate OTHER agents and humans across the AI-DLC lifecycle by delegating ideas and tasks, running independent reviewers, and gatekeeping at the Reversed-Conversation gates.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.18.0"
  category: project-management
  mcp_server: 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:

• `/skill:yolo` — **one** agent drives the whole pipeline solo. Orchestration is the opposite: **many** agents, each owning a piece, coordinated by you.
• `/skill:idea`, `/skill:proposal`, `/skill:develop`, `/skill:review`, `/skill:quick-dev` — 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:

| Param | Meaning | |-------|---------| | `ideaUuid` | The idea to delegate | | `assigneeType` | `"agent"` or `"user"` | | `assigneeUuid` | The chosen agent/user UUID (resolve names with `chorus_search_mentionables`) | | `instanceUuid` | *(optional, agent targets only)* pin the work to one durable AgentInstance — the `(agent, host, cwd)` place — so wakes land where the code lives |

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

The extension ships three read-only reviewer subagents. As orchestrator you spawn them at the three gates and act on the verdict — this is your primary quality lever when you are not writing the code yourself.

| Reviewer subagent | Spawn after | Reviews | |-------------------|-------------|---------| | `chorus-proposal-reviewer` | a proposal is submitted | proposal draft quality (VERDICT on the proposal) | | `chorus-task-reviewer` | a task is submitted for verify | one task vs its acceptance criteria (VERDICT on the task) | | `chorus-code-reviewer` | the idea's last task is verified | the idea's **aggregate** code change — the final ship gateway (VERDICT on the idea) |

Spawn a reviewer via `subagent_spawn` with the reviewer skill and the target UUID; after it posts, `subagent_manage close` it to release Pi's concurrency slot. 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 `/skill:quick-dev` and re-run once they are `done`). See `/skill:review` for the full pattern.

---

Choosing a collaboration mode

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

| Mode | Use when | How you run it | |------|----------|----------------| | **Single-owner drives one idea** | The work is one coherent feature | Assign the idea once (`chorus_pm_assign_idea`); that owner runs idea → proposal → tasks; you gatekeep the gates