Skip to content
Development
Skill

/review

Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.

From plugin
chorus
1.2k42 skills7 agents4 commands1 MCP
Install
$ npx -y skills add Chorus-AIDLC/Chorus --skill review --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/review

Context preview

The summary Claude sees to decide when to auto-load this skill.

Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.

SKILL.md

review.SKILL.md
name: review
description: Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.18.0"
  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.

---

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`)
  • **Task verification** — verify or reopen Tasks submitted by Developer Agents (see `/develop`)
  • **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, prefer spawning an independent reviewer sub-agent over reviewing manually:

1. **Try the reviewer first.** Spawn `chorus-proposal-reviewer` (for proposals), `chorus-task-reviewer` (for tasks), or `chorus-code-reviewer` (the final ship-time gateway over an Idea's aggregate code change, after its last task is verified — pass the `ideaUuid`; it posts its VERDICT on the **idea**) as a read-only sub-agent. **Use the blocking `subagent` tool** (it waits for the VERDICT and returns it) — you must wait for the VERDICT before proceeding. It posts a VERDICT comment with detailed findings. 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). 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.** Count existing VERDICT comments before spawning. After 3 rounds of FAIL on the same item, stop the loop and escalate to human review: post a comment saying the round limit was reached and a human decision is needed, and post no VERDICT. Nobody — including you on a later turn — may replace that escalation with a self-reviewed VERDICT. 5. **Fallback.** If the reviewer is unavailable (e.g., agent type not registered, sub-agent spawn fails), review the item yourself using the quality checklists in the workflows below.

---

Workflow

Step 1: Check In

chorus_checkin()

Pay attention to:

  • Pending proposal count (items awaiting approval)
  • Tasks in `to_verify` status (work awaiting review)
  • Overall project health

Step 2: Triage

Check what needs your attention:

# Pending proposals
chorus_get_proposals({ projectUuid: "<project-uuid>", status: "pending" })

# Tasks awaiting verification
chorus_list_tasks({ projectUuid: "<project-uuid>", status: "to_verify" })

# Recent activity
chorus_get_activity({ projectUuid: "<project-uuid>" })

Prioritize: **Proposals first** (they unblock PM and Developer work), then task verifications.

Workflow A: Proposal Review

A1: Read the Proposal

chorus_get_proposal({ proposalUuid: "<prop
Read more
Ships withchorus

The Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)

Get the whole plugin

Other skills on chorus.