Review

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:

PM + Admin (proposal reject/revoke):

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 the chorus-proposal-reviewer (proposal), chorus-task-reviewer (task), or chorus-code-reviewer (the final ship-time gateway over an Idea's aggregate code change, after its last task is verified — pass it the ideaUuid; it posts its VERDICT on the idea) by calling spawn_agent({items:[{type:"skill", path:"chorus:chorus-<kind>-reviewer"}, {type:"text", text:"Review <entity> <uuid> and post VERDICT."}]}). Wait with wait_agent because the gate depends on the VERDICT, then call close_agent as soon as no further reviewer interaction is needed.
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_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. 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.

Routine entity-backed reviewers use a fresh context and fetch authoritative state from Chorus. Set fork_context: true only when material parent-conversation evidence cannot be summarized in the text item. Use send_input for an active reviewer that needs correction; use resume_agent only for a reviewer that was already closed. Codex owns reviewer-thread orchestration, while Chorus MCP owns proposal/task state, acceptance evidence, and VERDICT comments.

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: "<proposal-uuid>", section: "full" })

chorus_get_proposal defaults to section: "basic" — proposal metadata plus a lightweight index of the drafts (uuid, type/title, contentLength, AC count, dependency edges) with no document content or full task descriptions. For a review you need the bodies, so pass section: "full" to get everything at once (or section: "documents" / section: "tasks" to read one kind at a time).

The full view returns: title, description, input ideas, document drafts (PRD, tech design), task drafts (with descriptions and acceptance criteria).