/orchestrate-chorus

name: orchestrate-chorus
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.24.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.

> **Tool namespace under dsh.** Bare tool names below (e.g. `chorus_pm_assign_idea`) are the readable form; the actual callable name is `mcp__chorus__`-prefixed (`mcp__chorus__chorus_pm_assign_idea`). See the namespace note in the core `chorus` skill.

It complements the other skills rather than replacing them:

• `yolo-chorus` — **one** agent drives the whole pipeline solo. (On a Team-managed Idea, yolo still routes product/development work to the Team — see below.) 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.

---

Session scope for CLI daemon wakes

These rules apply only to wakes handled by an updated Chorus CLI daemon that honors the server-delivered SSE `sessionId`. They do not upgrade OpenClaw, Hermes, or dsh-native session routing; those native runtimes retain their existing behavior. Older daemons may fall back to legacy entity/Idea routing, so do not assume task/review isolation there.

• **Task work:** `task:<uuid>` is a task-scoped session with no Idea-session memory. Fetch the current task, its proposal and documents, and its direct Idea from Chorus before starting work; do not rely on the orchestrator's conversation. Sibling tasks of the same Idea can run concurrently for one agent and may share the working directory. Before editing when siblings share the cwd, work in your own git worktree; the daemon does not create one for you.
• **Review work:** a Team review request sent with `chorus_request_review` uses `review:<type>:<uuid>`, where type is `proposal`, `task`, or `idea` (a code review targets the Idea). It is a read-only review-scoped session with no development-session memory. Fetch the target and current reviewer protocol/context before reviewing; do not implement fixes or perform lifecycle writes. A re-review by the same reviewer of the same target resumes the same review session, preserving review history rather than development memory.
• **Orchestration:** elaboration, proposal work, Start Development, Yolo, and orchestration stay in the bare direct-Idea UUID session (`<directIdeaUuid>`, not `idea:<uuid>`). An orchestrator also assigned a task uses `task:<uuid>` only for task-start/reopen work; its other task wakes (comments, mentions, PASS/FAIL VERDICT replies, Team handoffs) stay in the Idea session. Human instructions, operations, and research requests always use the Idea session, even for a task's developer.

These are backend conversation and wake-queue anchors, not the Chorus Agent Session `sessionUuid` used by session check-in tools. Session separation does not isolate files or change the host's existing session check-in lifecycle.

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 `instance