@chorus-aidlc/chorus 0.16.2 → 0.16.3

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-docs/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus documentation router — consult the live Chorus docs site t
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-idea/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Idea workflow — claim ideas, run elaboration rounds, and p
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -39,6 +39,7 @@ All post-elaboration progress (planning, building, verifying, done) is **derived
 | `chorus_edit_idea` | Edit an existing idea's title, description, and/or lineage parent. `parentUuid`: another same-project idea to reparent under, `null` to detach to top-level, omit to leave unchanged (cycle-checked + same-project). Single-parent **weak** lineage — a parent shows a read-only `+N derived` rollup but never blocks either idea's flow. Records an "edited" activity and signals presence. |
 | `chorus_claim_idea` | Claim an open idea (open -> elaborating) |
 | `chorus_release_idea` | Release a claimed idea (elaborating -> open) |
+| `chorus_pm_assign_idea` | Assign an idea to an agent (must hold `idea:write`) or a user, on a human's behalf — the counterpart to `chorus_claim_idea` (self-claim). Silently takes over any existing assignee; an `open` idea moves to `elaborating`, any other status is preserved. Optional `instanceUuid` pins an **agent** assignment to a specific AgentInstance (agent-only). Assigning to an agent wakes it best-effort (offline still persists the assignment); assigning to a user notifies them with no daemon wake. Requires `idea:admin`. |
 | `chorus_move_idea` | Move an Idea to a different Project. Cascade-migrates the Idea **and its full lineage subtree** (all descendant Ideas; the moved root is detached from any parent left behind), all linked Proposals (any status), all materialized Documents and Tasks, and all related Activities atomically. Comments, TaskDependency, AcceptanceCriterion, AgentSession, SessionTaskCheckin, Notification history, and Task assignees are NOT modified. Returns `moved: { ideas, proposals, documents, tasks, activities }` counts. Requires `idea:write` only — no project-level checks. |
 
 **Requirements Elaboration:**
@@ -46,7 +47,7 @@ All post-elaboration progress (planning, building, verifying, done) is **derived
 | Tool | Purpose |
 |------|---------|
 | `chorus_pm_start_elaboration` | Generate an elaboration round (first, follow-up, or appended-after-resolution) |
-| `chorus_pm_validate_elaboration` | Mark the whole elaboration complete (requires `idea:admin`; requires human confirmation first) |
+| `chorus_pm_validate_elaboration` | Mark the whole elaboration complete (requires `idea:admin`; requires human confirmation first) — callable by the Idea's assignee, or a non-assignee `idea:admin` gateway (wakes the assignee) |
 | `chorus_pm_skip_elaboration` | Skip elaboration for trivially clear Ideas |
 | `chorus_answer_elaboration` | Submit answers for an elaboration round (`roundUuid` optional — auto-locates the active round) |
 | `chorus_get_elaboration` | Get full elaboration state (rounds, questions, answers) |
@@ -155,7 +156,7 @@ If the Idea is fuzzy and you'd struggle to enumerate concrete multi-choice quest
 
 When `/chorus-brainstorm` returns, you own the lifecycle decision (the brainstorm skill deliberately leaves it to you):
 
-- If the synthesized round answers cover everything → obtain human confirmation, then call `chorus_pm_validate_elaboration` to resolve the elaboration. (Resolve needs `idea:admin` — see Step 5.6 if your key is `pm_agent`-preset.)
+- If the synthesized round answers cover everything → obtain human confirmation, then call `chorus_pm_validate_elaboration` to resolve the elaboration. (Resolve needs `idea:admin` — see Step 5.6 if your key is `pm_agent`-preset, or a non-assignee `idea:admin` gateway (wakes the assignee).)
 - If gaps remain → call `chorus_pm_start_elaboration` again to open a structured Round 2. Pick the depth yourself — do NOT re-prompt the user.
 
 Either outcome ends Step 4.5; skip Step 5.
@@ -270,7 +271,7 @@ chorus_pm_skip_elaboration({
 
    > **Permission (N1): `chorus_pm_validate_elaboration` requires `idea:admin`.** The `pm_agent` preset only grants `idea:write`, so a PM-preset agent **cannot** resolve — it must hand off to an `admin_agent`-preset agent (or an admin-preset API key) to perform the resolve. If your key lacks `idea:admin`, surface this to the human and request the handoff instead of failing silently.
 
-   > **Assignee precondition (N2):** the resolving actor must be the Idea's **assignee**. A separate human reviewer resolving a PM-owned Idea therefore needs **both** `idea:admin` **and** to be assigned the Idea (claim/reassign it first). Admin permission alone is not enough.
+   > **Assignee OR idea:admin gateway (N2):** the resolving actor may be the Idea's **assignee**, OR a non-assignee holding **`idea:admin`** acting as a gateway. A gateway resolve (or skip via `chorus_pm_skip_elaboration`) is the MCP analogue of the human UI **Verify-Elaborate**: it logs an `elaboration_verified` activity that wakes the Idea's **assignee** agent to write the proposal. So an orchestrator/admin no longer needs to claim/reassign the Idea to resolve it — holding `idea:admin` is enough. (Assignee self-resolve/skip is unchanged and wakes no one.)
 
    ```
    chorus_pm_validate_elaboration({

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-openspec-aware/SKILL.md

@@ -4,7 +4,7 @@ description: Opt-in OpenSpec-mode authoring for Chorus PM workflows in Kiro CLI.
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-orchestrate/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: chorus-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.16.3"
+  category: project-management
+  mcp_server: chorus
+---
+
+# 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:
+
+- `/chorus-yolo` — **one** agent drives the whole pipeline solo. Orchestration is the opposite: **many** agents, each owning a piece, coordinated by you.
+- `/chorus-idea`, `/chorus-proposal`, `/chorus-develop`, `/chorus-review`, `/chorus-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 plugin 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) |
+
+Kiro auto-selects a reviewer by its `description`, and each is also reachable as a `/name` slash command. 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 `/chorus-quick-dev` and re-run once they are `done`). See `/chorus-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 |
+| **Fan-out children to N agents** | A theme decomposes into independent slices | Derive child ideas, assign each to a distinct owner; children run in parallel, each single-owner |
+| **Parallel task waves** | One approved proposal with a task DAG | Assign the currently-unblocked tasks (`chorus_pm_assign_task`) to several dev agents; as tasks reach `done`, assign the next wave |
+| **Review-only** | Work is already produced elsewhere | Spawn the relevant reviewer, read the VERDICT, and gatekeep — no new delegation |
+
+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.
+
+---
+
+## Single-owner & concurrency discipline
+
+- **One responsible assignee per idea at a time.** This mirrors the daemon's single-owner semantics: the idea is the authoritative pin root, and its owner's proposals/tasks/wakes inherit that identity. Don't leave an idea ambiguously "owned by the team."
+- **Don't race duplicate sessions on the same work.** Two daemon sessions (or two agents) driving the same idea/task will collide on status transitions and produce conflicting wakes. Assign, then let one owner run.
+- **Pin with `instanceUuid` when the work is tied to a place.** If a child idea's code lives on a specific host/cwd, pin the assignment to that AgentInstance so every downstream wake lands there instead of a random daemon.
+
+---
+
+## Reversed-Conversation gates (you never auto-ship)
+
+Chorus is **AI proposes, humans verify**. As orchestrator you enforce that, you do not bypass it:
+
+- **Elaboration gate (gateway resolve/skip).** When a child idea you assigned to another agent has its elaboration answered, you can close the elaboration gate yourself via `chorus_pm_validate_elaboration` (or `chorus_pm_skip_elaboration` for a trivially clear idea) even though you are not the assignee — holding `idea:admin` is enough. This is the MCP parity of the UI Verify-Elaborate: it wakes the **assignee** agent to write the proposal. You gatekeep the gate; the assignee still authors the proposal (Reversed-Conversation preserved).
+- **Proposal gate.** When a delegated owner submits a proposal, STOP. Run the proposal reviewer, then hand the approve/reject decision to the human owner. Do not self-approve just because you *can* (`proposal:admin`).
+- **Verify gate.** When a task reaches `to_verify`, STOP. Run the task reviewer, then let the human verify. Permission to verify is not authorization to rubber-stamp your own coordinated work.
+- **Never merge or push.** The orchestrator drives work up to "PR ready" and hands it back to the human — it does not merge, push, or otherwise ship autonomously.
+
+@mention the owner at each gate so the handoff is explicit and auditable.
+
+---
+
+## Derive a child idea vs add a task vs assign directly
+
+| Do this | When |
+|---------|------|
+| **Derive a new child idea** (`chorus_pm_create_idea` + assign) | The slice is genuinely separate scope that deserves its own elaboration, proposal, and owner — a theme decomposition, or a parallelizable sub-feature. |
+| **Add a task to an approved proposal** (`chorus_create_tasks` with `proposalUuid`) | The work is a discrete unit of the **same** feature that already has a proposal — e.g. code-review fix tasks, or a follow-up step in an existing DAG. |
+| **Assign the existing idea/task directly** (`chorus_pm_assign_idea` / `chorus_pm_assign_task`) | The work is already scoped and just needs a (different) owner or executor — reassignment, taking over a stalled idea, or distributing existing tasks. |
+
+Rule of thumb: **new scope → child idea; same-proposal unit → task; only the owner changes → assign.**

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-quick-dev/SKILL.md

@@ -4,7 +4,7 @@ description: Quick Task workflow — skip Idea→Proposal, create tasks directly
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-review/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Review workflow — approve/reject proposals, verify tasks,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/skills/chorus-yolo/SKILL.md

@@ -4,7 +4,7 @@ description: Full-auto AI-DLC pipeline — from prompt to done. Automates the en
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/kiro-plugin/.kiro/steering/chorus.md

@@ -2,7 +2,7 @@
 
 Chorus is a work collaboration platform for AI Agents, enabling multiple Agents (PM, Developer, Admin) and humans to collaborate on the same platform through the **AI-DLC (AI Development Life Cycle)** workflow.
 
-This is the **always-on project-context steering doc** for the Chorus Kiro plugin. It carries the platform overview, the shared MCP tools, the AI-DLC lifecycle, the three roles, and the permission model. For a stage-specific workflow, invoke the matching skill (`/chorus-idea`, `/chorus-proposal`, `/chorus-develop`, `/chorus-yolo`, `/chorus-review`, `/chorus-quick-dev`, `/chorus-brainstorm`, `/chorus-openspec-aware`).
+This is the **always-on project-context steering doc** for the Chorus Kiro plugin. It carries the platform overview, the shared MCP tools, the AI-DLC lifecycle, the three roles, and the permission model. For a stage-specific workflow, invoke the matching skill (`/chorus-idea`, `/chorus-proposal`, `/chorus-develop`, `/chorus-yolo`, `/chorus-orchestrate`, `/chorus-review`, `/chorus-quick-dev`, `/chorus-brainstorm`, `/chorus-openspec-aware`).
 
 > **Why this is steering, not a skill.** The `chorus` **main agent** owns the `/chorus` slash command, so the platform overview lives here as steering instead of a `/chorus` skill. Steering is auto-loaded by the default agent and referenced by every `chorus*` agent's `resources`, so this context is always present.
 
@@ -389,6 +389,7 @@ The `chorus` main agent owns `/chorus` and pre-loads all skills below. For stage
 | Stage | Skill | Description |
 |-------|-------|-------------|
 | **Full Auto** | `/chorus-yolo` | Full-auto AI-DLC pipeline — from prompt to done. Automates Idea → Proposal → Execute → Verify with adversarial reviewers |
+| **Orchestration** | `/chorus-orchestrate` | Coordinate OTHER agents & humans across the lifecycle — delegate ideas (`chorus_pm_assign_idea`) & tasks, fan a theme out to child ideas, run independent reviewers, and gatekeep the proposal/verify gates |
 | **Quick Dev** | `/chorus-quick-dev` | Skip Idea→Proposal, create tasks directly, execute, and verify |
 | **Ideation** | `/chorus-idea` | Claim Ideas, run elaboration rounds, prepare for proposal |
 | **Planning** | `/chorus-proposal` | Create Proposals with document & task drafts, manage dependency DAG, submit for review |

package/.next/standalone/public/kiro-plugin/bin/chorus-api.sh

@@ -240,7 +240,7 @@ cmd_mcp_tool() {
     # Step 1: Initialize MCP session
     local init_payload
     init_payload=$(cat <<JSONEOF
-{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"chorus-hook","version":"0.16.2"}}}
+{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"chorus-hook","version":"0.16.3"}}}
 JSONEOF
 )
 

package/.next/standalone/public/skill/brainstorm-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Optional divergent-then-convergent dialogue for fuzzy ideas. Invoke
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus AI Agent collaboration platform — overview, common tools,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -463,6 +463,7 @@ This is the core overview skill. For stage-specific workflows, download and read
 | **Task Review** | `task-reviewer-chorus` | `<BASE_URL>/skill/task-reviewer-chorus/SKILL.md` |
 | **Code Review (ship gateway)** | `code-reviewer-chorus` | `<BASE_URL>/skill/code-reviewer-chorus/SKILL.md` |
 | **Full-Auto** | `yolo-chorus` | `<BASE_URL>/skill/yolo-chorus/SKILL.md` |
+| **Orchestration** | `orchestrate-chorus` | `<BASE_URL>/skill/orchestrate-chorus/SKILL.md` |
 
 ### Getting Started
 

package/.next/standalone/public/skill/code-reviewer-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Read-only adversarial Chorus code-review gateway — independently
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/develop-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Development workflow — claim tasks, report work, self-chec
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/docs-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus documentation router — consult the live Chorus docs site t
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/idea-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Idea workflow — claim ideas, run elaboration rounds, and p
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -39,6 +39,7 @@ All post-elaboration progress (planning, building, verifying, done) is **derived
 | `chorus_edit_idea` | Edit an existing idea's title, description, and/or lineage parent. `parentUuid`: another same-project idea to reparent under, `null` to detach to top-level, omit to leave unchanged (cycle-checked + same-project). Single-parent **weak** lineage — a parent shows a read-only `+N derived` rollup but never blocks either idea's flow. Records an "edited" activity and signals presence. |
 | `chorus_claim_idea` | Claim an open idea (open -> elaborating) |
 | `chorus_release_idea` | Release a claimed idea (elaborating -> open) |
+| `chorus_pm_assign_idea` | Assign an idea to an agent (must hold `idea:write`) or a user, on a human's behalf — the counterpart to `chorus_claim_idea` (self-claim). Silently takes over any existing assignee; an `open` idea moves to `elaborating`, any other status is preserved. Optional `instanceUuid` pins an **agent** assignment to a specific AgentInstance (agent-only). Assigning to an agent wakes it best-effort (offline still persists the assignment); assigning to a user notifies them with no daemon wake. Requires `idea:admin`. |
 | `chorus_move_idea` | Move an Idea to a different Project. Cascade-migrates the Idea **and its full lineage subtree** (all descendant Ideas; the moved root is detached from any parent left behind), all linked Proposals (any status), all materialized Documents and Tasks, and all related Activities atomically. Comments, TaskDependency, AcceptanceCriterion, AgentSession, SessionTaskCheckin, Notification history, and Task assignees are NOT modified. Returns `moved: { ideas, proposals, documents, tasks, activities }` counts. Requires `idea:write` only — no project-level checks. |
 
 **Requirements Elaboration:**
@@ -46,7 +47,7 @@ All post-elaboration progress (planning, building, verifying, done) is **derived
 | Tool | Purpose |
 |------|---------|
 | `chorus_pm_start_elaboration` | Generate an elaboration round (first, follow-up, or appended-after-resolution) |
-| `chorus_pm_validate_elaboration` | Mark the whole elaboration complete (requires `idea:admin`; requires human confirmation first) |
+| `chorus_pm_validate_elaboration` | Mark the whole elaboration complete (requires `idea:admin`; requires human confirmation first) — callable by the Idea's assignee, or a non-assignee `idea:admin` gateway (wakes the assignee) |
 | `chorus_pm_skip_elaboration` | Skip elaboration for trivially clear Ideas |
 | `chorus_answer_elaboration` | Submit answers for an elaboration round (`roundUuid` optional — auto-locates the active round) |
 | `chorus_get_elaboration` | Get full elaboration state (rounds, questions, answers) |
@@ -155,7 +156,7 @@ If the Idea is fuzzy and you'd struggle to enumerate concrete multi-choice quest
 
 When the brainstorm skill returns, you own the lifecycle decision (the brainstorm skill deliberately leaves it to you):
 
-- If the synthesized round answers cover everything → obtain human confirmation, then call `chorus_pm_validate_elaboration` to resolve the elaboration. (Resolve needs `idea:admin` — see Step 5.6 if your key is `pm_agent`-preset.)
+- If the synthesized round answers cover everything → obtain human confirmation, then call `chorus_pm_validate_elaboration` to resolve the elaboration. (Resolve needs `idea:admin` — see Step 5.6 if your key is `pm_agent`-preset, or a non-assignee `idea:admin` gateway (wakes the assignee).)
 - If gaps remain → call `chorus_pm_start_elaboration` again to open a structured Round 2. Pick the depth yourself — do NOT re-prompt the user.
 
 Either outcome ends Step 4.5; skip Step 5.
@@ -281,7 +282,7 @@ chorus_pm_skip_elaboration({
 
    > **Permission (N1): `chorus_pm_validate_elaboration` requires `idea:admin`.** The `pm_agent` preset only grants `idea:write`, so a PM-preset agent **cannot** resolve — it must hand off to an `admin_agent`-preset agent (or an admin-preset API key) to perform the resolve. If your key lacks `idea:admin`, surface this to the human and request the handoff instead of failing silently.
 
-   > **Assignee precondition (N2):** the resolving actor must be the Idea's **assignee**. A separate human reviewer resolving a PM-owned Idea therefore needs **both** `idea:admin` **and** to be assigned the Idea (claim/reassign it first). Admin permission alone is not enough.
+   > **Assignee OR idea:admin gateway (N2):** the resolving actor may be the Idea's **assignee**, OR a non-assignee holding **`idea:admin`** acting as a gateway. A gateway resolve (or skip via `chorus_pm_skip_elaboration`) is the MCP analogue of the human UI **Verify-Elaborate**: it logs an `elaboration_verified` activity that wakes the Idea's **assignee** agent to write the proposal. So an orchestrator/admin no longer needs to claim/reassign the Idea to resolve it — holding `idea:admin` is enough. (Assignee self-resolve/skip is unchanged and wakes no one.)
 
    ```
    chorus_pm_validate_elaboration({

package/.next/standalone/public/skill/orchestrate-chorus/SKILL.md

@@ -0,0 +1,128 @@
+---
+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.16.3"
+  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:
+
+- `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:
+
+| 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
+
+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.
+
+| Reviewer skill | Run after | Reviews |
+|----------------|-----------|---------|
+| `proposal-reviewer-chorus` | a proposal is submitted | proposal draft quality (VERDICT on the proposal) |
+| `task-reviewer-chorus` | a task is submitted for verify | one task vs its acceptance criteria (VERDICT on the task) |
+| `code-reviewer-chorus` | the idea's last task is verified | the idea's **aggregate** code change — the final ship gateway (VERDICT on the idea) |
+
+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. 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.
+
+---
+
+## 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 |
+| **Fan-out children to N agents** | A theme decomposes into independent slices | Derive child ideas, assign each to a distinct owner; children run in parallel, each single-owner |
+| **Parallel task waves** | One approved proposal with a task DAG | Assign the currently-unblocked tasks (`chorus_pm_assign_task`) to several dev agents; as tasks reach `done`, assign the next wave |
+| **Review-only** | Work is already produced elsewhere | Spawn the relevant reviewer, read the VERDICT, and gatekeep — no new delegation |
+
+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.
+
+---
+
+## Single-owner & concurrency discipline
+
+- **One responsible assignee per idea at a time.** This mirrors the daemon's single-owner semantics: the idea is the authoritative pin root, and its owner's proposals/tasks/wakes inherit that identity. Don't leave an idea ambiguously "owned by the team."
+- **Don't race duplicate sessions on the same work.** Two daemon sessions (or two agents) driving the same idea/task will collide on status transitions and produce conflicting wakes. Assign, then let one owner run.
+- **Pin with `instanceUuid` when the work is tied to a place.** If a child idea's code lives on a specific host/cwd, pin the assignment to that AgentInstance so every downstream wake lands there instead of a random daemon.
+
+---
+
+## Reversed-Conversation gates (you never auto-ship)
+
+Chorus is **AI proposes, humans verify**. As orchestrator you enforce that, you do not bypass it:
+
+- **Elaboration gate (gateway resolve/skip).** When a child idea you assigned to another agent has its elaboration answered, you can close the elaboration gate yourself via `chorus_pm_validate_elaboration` (or `chorus_pm_skip_elaboration` for a trivially clear idea) even though you are not the assignee — holding `idea:admin` is enough. This is the MCP parity of the UI Verify-Elaborate: it wakes the **assignee** agent to write the proposal. You gatekeep the gate; the assignee still authors the proposal (Reversed-Conversation preserved).
+- **Proposal gate.** When a delegated owner submits a proposal, STOP. Run the proposal reviewer, then hand the approve/reject decision to the human owner. Do not self-approve just because you *can* (`proposal:admin`).
+- **Verify gate.** When a task reaches `to_verify`, STOP. Run the task reviewer, then let the human verify. Permission to verify is not authorization to rubber-stamp your own coordinated work.
+- **Never merge or push.** The orchestrator drives work up to "PR ready" and hands it back to the human — it does not merge, push, or otherwise ship autonomously.
+
+@mention the owner at each gate so the handoff is explicit and auditable.
+
+---
+
+## Derive a child idea vs add a task vs assign directly
+
+| Do this | When |
+|---------|------|
+| **Derive a new child idea** (`chorus_pm_create_idea` + assign) | The slice is genuinely separate scope that deserves its own elaboration, proposal, and owner — a theme decomposition, or a parallelizable sub-feature. |
+| **Add a task to an approved proposal** (`chorus_create_tasks` with `proposalUuid`) | The work is a discrete unit of the **same** feature that already has a proposal — e.g. code-review fix tasks, or a follow-up step in an existing DAG. |
+| **Assign the existing idea/task directly** (`chorus_pm_assign_idea` / `chorus_pm_assign_task`) | The work is already scoped and just needs a (different) owner or executor — reassignment, taking over a stalled idea, or distributing existing tasks. |
+
+Rule of thumb: **new scope → child idea; same-proposal unit → task; only the owner changes → assign.**

package/.next/standalone/public/skill/proposal-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/proposal-reviewer-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Read-only adversarial Chorus proposal reviewer — audits PRD/task
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/quick-dev-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Quick Task workflow — skip Idea→Proposal, create tasks directly
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/review-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Review workflow — approve/reject proposals, verify tasks,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/task-reviewer-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Read-only adversarial Chorus task reviewer — independently verifi
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.2"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/skill/yolo-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Full-auto AI-DLC pipeline — drive a single prompt from Idea throu
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.16.0"
+  version: "0.16.3"
   category: project-management
   mcp_server: chorus
 ---

package/cli/prompts.mjs

@@ -320,10 +320,20 @@ function buildPromptBody(n) {
       );
     }
     case "idea_claimed":
+      // The assignment ALREADY set you as the assignee, so there is nothing to claim —
+      // chorus_claim_idea would throw (AlreadyClaimedError, and a hard "Cannot claim an
+      // elaborated Idea" for the elaborated-backfill case). Do NOT emit a claim
+      // instruction here (a prompt test asserts the literal never appears). Instead tell
+      // the already-assigned agent to review and advance from the idea's CURRENT stage,
+      // stopping at the human proposal/verify gates. Names the assigner via n.actorName /
+      // n.actorType (already on the notification — no server change). Mirrored in the
+      // OpenClaw twin handleIdeaClaimed (event-router.ts) — KEEP THE TWO WORDINGS IN SYNC.
       return (
-        `[Chorus] Idea '${n.entityTitle}' was assigned to you (ideaUuid: ${n.entityUuid}, ` +
-        `projectUuid: ${n.projectUuid}). Use chorus_get_idea to review it, then claim it ` +
-        `(chorus_claim_idea) to begin elaboration.\n${mentionGuidance(n, "idea")}`
+        `[Chorus] Idea '${n.entityTitle}' was assigned to you by ${n.actorName} (${n.actorType}) ` +
+        `(ideaUuid: ${n.entityUuid}, projectUuid: ${n.projectUuid}). You are now the assignee — no need ` +
+        `to claim it. Use chorus_get_idea to review it, then advance it from its CURRENT stage: if it is ` +
+        `still elaborating, run or continue elaboration; if it is already elaborated, author the proposal. ` +
+        `Stop at the human proposal/verify gates and never merge automatically.\n${mentionGuidance(n, "idea")}`
       );
     case "task_reopened":
       return (

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chorus-aidlc/chorus",
-  "version": "0.16.2",
+  "version": "0.16.3",
   "description": "The Agent Harness for AI-Human Collaboration — session lifecycle, task state, sub-agent orchestration, observability, and failure recovery",
   "homepage": "https://github.com/Chorus-AIDLC/Chorus",
   "repository": {
@@ -64,6 +64,8 @@
   },
   "dependencies": {
     "@bprogress/next": "^3.2.12",
+    "@dicebear/core": "^10",
+    "@dicebear/styles": "^10",
     "@electric-sql/pglite": "^0.4.4",
     "@electric-sql/pglite-socket": "^0.1.4",
     "@floating-ui/dom": "^1.7.5",