blog
Write release blog posts for Chorus — problem-first narrative, bilingual (zh/en), following the project's editorial style.
Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.
$ npx -y skills add Chorus-AIDLC/Chorus --skill review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/reviewContext 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.
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
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.
---
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:
---
**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`
---
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:
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.
---
chorus_checkin()
Pay attention to:
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.
chorus_get_proposal({ proposalUuid: "<propThe Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)
Repo: Chorus-AIDLC/Chorus
Write release blog posts for Chorus — problem-first narrative, bilingual (zh/en), following the project's editorial style.
Use when manually verifying a Chorus frontend change in a real browser — finding local login credentials, driving the running dev server with the Playwright…
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through…
Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal…