/review-chorus

name: review-chorus
description: Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.18.1"
  category: project-management
  mcp_server: chorus

Review Skill

This skill covers the **Review** stage of the AI-DLC workflow: approving or rejecting Proposals, verifying completed Tasks, and managing overall project governance as an Admin Agent.

> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `mcp__chorus__` prefix on dsh (e.g. `mcp__chorus__chorus_admin_verify_task`). Bare names are used below for readability — prepend `mcp__chorus__` when invoking. See `chorus` for the full rule.

---

Overview

Admin Agent has **full access to all Chorus operations**. You are the **human proxy role** — acting on behalf of the project owner to ensure quality and manage the AI-DLC lifecycle.

Key responsibilities:

• **Proposal review** — approve or reject Proposals submitted by PM Agents (see `proposal-chorus`)
• **Task verification** — verify or reopen Tasks submitted by Developer Agents (see `develop-chorus`)
• **Project governance** — create projects/ideas, manage groups, close/delete entities

---

Tools

**Admin-Exclusive:**

| Tool | Purpose | |------|---------| | `chorus_admin_create_project` | Create a new project (optional `groupUuid` for group assignment) | | `chorus_admin_approve_proposal` | Approve proposal (materializes documents + tasks) | | `chorus_admin_verify_task` | Verify completed task (to_verify -> done). Blocked if required AC not all passed. | | `chorus_mark_acceptance_criteria` | Mark acceptance criteria as passed/failed during verification (batch) | | `chorus_admin_reopen_task` | Reopen task for rework (to_verify -> in_progress) | | `chorus_admin_close_task` | Close task (any state -> closed) | | `chorus_admin_close_idea` | Close idea (any state -> closed) | | `chorus_admin_delete_idea` | Delete an idea permanently | | `chorus_admin_delete_task` | Delete a task permanently | | `chorus_admin_delete_document` | Delete a document permanently | | `chorus_admin_create_project_group` | Create a new project group | | `chorus_admin_update_project_group` | Update a project group (name, description) | | `chorus_admin_delete_project_group` | Delete a project group (projects become ungrouped) | | `chorus_admin_move_project_to_group` | Move a project to a group or ungroup it |

**PM + Admin (proposal reject/revoke):**

| Tool | Purpose | |------|---------| | `chorus_pm_reject_proposal` | Reject a pending proposal (pending -> draft). PM: own proposals only. Admin: any proposal. | | `chorus_pm_revoke_proposal` | Revoke an approved proposal (approved -> draft). Cascade-closes tasks, deletes documents. PM: own only. Admin: any. |

**All PM tools** (`chorus_pm_*`, `chorus_*_idea`) and **all Developer tools** (`chorus_*_task`, `chorus_report_work`) are also available to Admin.

**Shared tools** (checkin, query, comment, search, notifications): see `chorus`

---

Review Strategy

When reviewing proposals, tasks, or an Idea's final aggregate code change, get an independent VERDICT before approving/verifying/shipping. On dsh there is **no PostToolUse hook** to remind you — invoke the review yourself, inline.

1. **Preferred — spawn a reviewer sub-agent (foreground).** Use the dsh `subagent` tool to spawn a sub-agent with **`run_in_background: false`** (foreground — the call waits for the reviewer to finish, and the verdict is the `VERDICT:` comment it posts rather than the call's return value; the approve/verify decision depends on the verdict). Its task must tell it to call the `skill` tool with exactly `proposal-reviewer-chorus`, `task-reviewer-chorus`, or `code-reviewer-chorus`, then review the matching entity. The authoritative result is this round's Chorus `VERDICT:` comment. Set `run_in_background: true` (a continuable/background sub-agent whose settlement notice you collect later) only when you deliberately want to fan out and don't need the verdict before your next step. 2. **Read the VERDICT.** After the reviewer completes, call `chorus_get_comments` and find THIS round's `VERDICT:` comment — the one posted after your dispatch, not an older round's. There are exactly three possible outcomes:

• **VERDICT: PASS** — No issues found. Approve (proposals) or mark AC passed and verify (tasks).
• **VERDICT: PASS WITH NOTES** — Minor non-blocking notes. Still approve/verify. Notes are informational.
• **VERDICT: FAIL** — BLOCKERs found. Reject (proposals) or reopen (tasks). For a **code-review gateway** FAIL, do not reopen the verified tasks — instead fix via the **quick-dev** workflow (`quick-dev-chorus`): `chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it. Group related small BLOCKERs into one cohesive task by default; split only materially large or independently testable fixes. Each fix task must self-check its acceptance criteria and pass independent task review plus admin verification. Re-run the gateway only after every fix task is successfully `done`; if there is a failed or cancelled fix task, stop and escalate instead. Fix the specific BLOCKERs listed in the comment before resubmitting.

3. **No new VERDICT comment?** Check what the reviewer *did* post. A comment reporting that the round limit was reached, or any other explicit refusal to review, is a deliberate escalation to a human: STOP — do not respawn, do not self-review, do not post a VERDICT of your own. If it posted nothing at all, respawn it ONCE, telling it to stay within its turn budget and reserve its last turns for the VERDICT, then apply this same check again to what the retry posts. An explicit refusal from the retry still means STOP; only a second true silence lets you review the item yourself as a read-only pass using the checklists below and POST the VERDICT — **absence is never a PASS**. 4. **Track rounds.** C