Review 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-chorus skill at <BASE_URL>/skill/proposal-chorus/SKILL.md)
• Task verification — verify or reopen Tasks submitted by Developer Agents (see develop-chorus skill at <BASE_URL>/skill/develop-chorus/SKILL.md)
• Project governance — create projects/ideas, manage groups, close/delete entities

First-principles alignment (a stage-tailored instruction in all three reviewers). The proposal-, task-, and code-reviewer each also verify, top-down, that the work still serves the original Idea's intent — resolving the Idea from the entity under review and reading it via the existing chorus_get_idea + chorus_get_elaboration + chorus_get_comments (intent counts human-authored content only) and flagging scope creep, requirement loss / shrink, or semantic drift. Unauthorized drift is a BLOCKER → VERDICT: FAIL / reject, downgraded to a cited NOTE only when traceable to a human-originated authorization (a human-authored Idea comment, a human-answered elaboration entry, or an explicit human override at the gate) — an agent's own comment never authorizes. So a review FAIL may come from intent drift, not just a local defect: treat it the same way — reject/reopen and fix, or record a human override. See the canonical Independent Review section in the chorus skill (<BASE_URL>/skill/chorus/SKILL.md) for the full rule.

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 skill (<BASE_URL>/skill/chorus/SKILL.md)

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).

A2: Quality Checklist

Documents:

• PRD clearly describes the what and why
• Requirements are specific and testable
• Tech design is feasible and follows project conventions
• No missing edge cases or security considerations

Tasks:

• Tasks cover all requirements in the PRD
• Each task has clear acceptance criteria
• Tasks are appropriately sized (1-8 story points)
• Task descriptions have enough context for a developer agent
• Priority is set correctly

Overall:

• Proposal aligns with the original idea(s)
• No scope creep beyond what was requested
• Implementation approach is reasonable

A3: Read Comments

chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })

A3.5: Independent Review

Before approving, run an independent review of the proposal. Spawn a read-only sub-agent that loads the proposal-reviewer-chorus skill (<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md), pass it the proposalUuid, and let it adversarially audit document quality, task granularity, AC alignment, and the dependency DAG. It posts a single VERDICT comment (PASS / PASS WITH NOTES / FAIL) on the proposal; read THIS round's verdict comment — the one posted after your dispatch, not an older round's — with chorus_get_comments before deciding.

The spawn mechanism is harness-specific, and an inline self-review fallback exists when sub-agents are unavailable — see the canonical Independent Review section in the chorus skill (<BASE_URL>/skill/chorus/SKILL.md) for the full pattern.

VERDICT: FAIL is advisory — the reviewer's opinion does not block approval. The admin reads the review comment and makes the final decision.

A4: Approve or Reject

Approve:

chorus_admin_approve_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "Approved. Good breakdown of tasks."
})

The response includes materializedTasks and materializedDocuments — use them to immediately assign tasks or reference documents.

When approved:

• Document drafts become real Documents
• Task drafts become real Tasks (status: open)

Reject:

chorus_pm_reject_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "PRD missing error handling requirements. Task 3 needs clearer AC."
})

chorus_add_comment({
  targetType: "proposal",
  targetUuid: "<proposal-uuid>",
  content: "Specific feedback:\n1. Add error scenarios to PRD\n2. Task 3 AC should include performance benchmarks"
})

Workflow A2: Revoking Approved Proposals

If an approved Proposal's direction turns out to be wrong, use chorus_pm_revoke_proposal to undo the approval. Unlike reject (which acts on pending proposals), revoke acts on already-approved proposals and rolls back all materialized resources.

chorus_pm_revoke_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "Requirements changed — original approach no longer viable."
})

Cascade effects: all materialized Tasks are closed, all materialized Documents are deleted, and related AcceptanceCriteria/TaskDependencies/SessionCheckins are cleaned up. The Proposal returns to draft status so the PM can revise and resubmit.

Workflow B: Task Verification

B1: Review the Submitted Task

chorus_get_task({ taskUuid: "<task-uuid>" })

Check: developer's work summary, acceptance criteria, self-check results.

B2: Read Comments and Work Reports

chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })

B2.5: Independent Review

Before marking acceptance criteria and verifying, run an independent review of the task. Spawn a read-only sub-agent that loads the task-reviewer-chorus skill (<BASE_URL>/skill/task-reviewer-chorus/SKILL.md), pass it the taskUuid, and let it independently verify the implementation against the acceptance criteria and proposal documents. It posts a single VERDICT comment (PASS / PASS WITH NOTES / FAIL) on the task; read THIS round's verdict comment — the one posted after your dispatch, not an older round's — with chorus_get_comments before deciding.

The spawn mechanism is harness-specific, and an inline self-review fallback exists when sub-agents are unavailable — see the canonical Independent Review section in the chorus skill (<BASE_URL>/skill/chorus/SKILL.md) for the full pattern.

VERDICT is advisory — a FAIL does not block verification and a PASS does not auto-verify. The admin reads the review comment, marks the acceptance criteria, and makes the final decision.