@chorus-aidlc/chorus-pi 0.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,363 @@
1
+ ---
2
+ name: review
3
+ description: Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.
4
+ license: AGPL-3.0
5
+ metadata:
6
+ author: chorus
7
+ version: "0.17.0"
8
+ category: project-management
9
+ mcp_server: chorus
10
+ ---
11
+
12
+ # Review Skill
13
+
14
+ 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.
15
+
16
+ ---
17
+
18
+ ## Overview
19
+
20
+ 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.
21
+
22
+ Key responsibilities:
23
+ - **Proposal review** — approve or reject Proposals submitted by PM Agents (see `/proposal`)
24
+ - **Task verification** — verify or reopen Tasks submitted by Developer Agents (see `/develop`)
25
+ - **Project governance** — create projects/ideas, manage groups, close/delete entities
26
+
27
+ ---
28
+
29
+ ## Tools
30
+
31
+ **Admin-Exclusive:**
32
+
33
+ | Tool | Purpose |
34
+ |------|---------|
35
+ | `chorus_admin_create_project` | Create a new project (optional `groupUuid` for group assignment) |
36
+ | `chorus_admin_approve_proposal` | Approve proposal (materializes documents + tasks) |
37
+ | `chorus_admin_verify_task` | Verify completed task (to_verify -> done). Blocked if required AC not all passed. |
38
+ | `chorus_mark_acceptance_criteria` | Mark acceptance criteria as passed/failed during verification (batch) |
39
+ | `chorus_admin_reopen_task` | Reopen task for rework (to_verify -> in_progress) |
40
+ | `chorus_admin_close_task` | Close task (any state -> closed) |
41
+ | `chorus_admin_close_idea` | Close idea (any state -> closed) |
42
+ | `chorus_admin_delete_idea` | Delete an idea permanently |
43
+ | `chorus_admin_delete_task` | Delete a task permanently |
44
+ | `chorus_admin_delete_document` | Delete a document permanently |
45
+ | `chorus_admin_create_project_group` | Create a new project group |
46
+ | `chorus_admin_update_project_group` | Update a project group (name, description) |
47
+ | `chorus_admin_delete_project_group` | Delete a project group (projects become ungrouped) |
48
+ | `chorus_admin_move_project_to_group` | Move a project to a group or ungroup it |
49
+
50
+ **PM + Admin (proposal reject/revoke):**
51
+
52
+ | Tool | Purpose |
53
+ |------|---------|
54
+ | `chorus_pm_reject_proposal` | Reject a pending proposal (pending -> draft). PM: own proposals only. Admin: any proposal. |
55
+ | `chorus_pm_revoke_proposal` | Revoke an approved proposal (approved -> draft). Cascade-closes tasks, deletes documents. PM: own only. Admin: any. |
56
+
57
+ **All PM tools** (`chorus_pm_*`, `chorus_*_idea`) and **all Developer tools** (`chorus_*_task`, `chorus_report_work`) are also available to Admin.
58
+
59
+ **Shared tools** (checkin, query, comment, search, notifications): see `/chorus`
60
+
61
+ ---
62
+
63
+ ## Review Strategy
64
+
65
+ When reviewing proposals, tasks, or an Idea's final aggregate code change, prefer spawning an independent reviewer sub-agent over reviewing manually:
66
+
67
+ 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.
68
+ 2. **Read the VERDICT.** After the reviewer completes, call `chorus_get_comments` and find the most recent comment containing `VERDICT:`. There are exactly three possible outcomes:
69
+ - **VERDICT: PASS** — No issues found. Approve (proposals) or mark AC passed and verify (tasks).
70
+ - **VERDICT: PASS WITH NOTES** — Minor non-blocking notes. Still approve/verify. Notes are informational.
71
+ - **VERDICT: FAIL** — BLOCKERs found. Reject (proposals) or reopen (tasks). Fix the specific BLOCKERs listed in the comment before resubmitting.
72
+ 3. **No new VERDICT comment?** The reviewer exhausted its turn budget before posting. Respawn it ONCE with an explicit prompt like: *"Stay within your turn budget. Skip deep source verification — batch all MCP fetches up front, skim for obvious BLOCKERs only, and reserve your last few turns to post the VERDICT comment."* If the second attempt also fails to post, review manually using the checklists below.
73
+ 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.
74
+ 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.
75
+
76
+ ---
77
+
78
+ ## Workflow
79
+
80
+ ### Step 1: Check In
81
+
82
+ ```
83
+ chorus_checkin()
84
+ ```
85
+
86
+ Pay attention to:
87
+ - Pending proposal count (items awaiting approval)
88
+ - Tasks in `to_verify` status (work awaiting review)
89
+ - Overall project health
90
+
91
+ ### Step 2: Triage
92
+
93
+ Check what needs your attention:
94
+
95
+ ```
96
+ # Pending proposals
97
+ chorus_get_proposals({ projectUuid: "<project-uuid>", status: "pending" })
98
+
99
+ # Tasks awaiting verification
100
+ chorus_list_tasks({ projectUuid: "<project-uuid>", status: "to_verify" })
101
+
102
+ # Recent activity
103
+ chorus_get_activity({ projectUuid: "<project-uuid>" })
104
+ ```
105
+
106
+ Prioritize: **Proposals first** (they unblock PM and Developer work), then task verifications.
107
+
108
+ ### Workflow A: Proposal Review
109
+
110
+ #### A1: Read the Proposal
111
+
112
+ ```
113
+ chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
114
+ ```
115
+
116
+ `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).
117
+
118
+ The `full` view returns: title, description, input ideas, **document drafts** (PRD, tech design), **task drafts** (with descriptions and acceptance criteria).
119
+
120
+ #### A2: Quality Checklist
121
+
122
+ **Documents:**
123
+ - [ ] PRD clearly describes the *what* and *why*
124
+ - [ ] Requirements are specific and testable
125
+ - [ ] Tech design is feasible and follows project conventions
126
+ - [ ] No missing edge cases or security considerations
127
+
128
+ **Tasks:**
129
+ - [ ] Tasks cover all requirements in the PRD
130
+ - [ ] Each task has clear acceptance criteria
131
+ - [ ] Tasks are appropriately sized (1-8 story points)
132
+ - [ ] Task descriptions have enough context for a developer agent
133
+ - [ ] Priority is set correctly
134
+
135
+ **Overall:**
136
+ - [ ] Proposal aligns with the original idea(s)
137
+ - [ ] No scope creep beyond what was requested
138
+ - [ ] Implementation approach is reasonable
139
+
140
+ #### A3: Read Comments
141
+
142
+ ```
143
+ chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
144
+ ```
145
+
146
+ #### A3.5: Independent Review
147
+
148
+ Spawn `chorus-proposal-reviewer` per the [Review Strategy](#review-strategy) above — use the blocking `subagent` tool (it waits). Read its VERDICT comment before proceeding.
149
+
150
+ #### A4: Approve or Reject
151
+
152
+ **Approve:**
153
+
154
+ ```
155
+ chorus_admin_approve_proposal({
156
+ proposalUuid: "<proposal-uuid>",
157
+ reviewNote: "Approved. Good breakdown of tasks."
158
+ })
159
+ ```
160
+
161
+ The response includes `materializedTasks` and `materializedDocuments` — use them to immediately assign tasks or reference documents.
162
+
163
+ When approved:
164
+ - Document drafts become real Documents
165
+ - Task drafts become real Tasks (status: `open`)
166
+
167
+ **Reject:**
168
+
169
+ ```
170
+ chorus_pm_reject_proposal({
171
+ proposalUuid: "<proposal-uuid>",
172
+ reviewNote: "PRD missing error handling requirements. Task 3 needs clearer AC."
173
+ })
174
+
175
+ chorus_add_comment({
176
+ targetType: "proposal",
177
+ targetUuid: "<proposal-uuid>",
178
+ content: "Specific feedback:\n1. Add error scenarios to PRD\n2. Task 3 AC should include performance benchmarks"
179
+ })
180
+ ```
181
+
182
+ ### Workflow A2: Revoking Approved Proposals
183
+
184
+ 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.
185
+
186
+ ```
187
+ chorus_pm_revoke_proposal({
188
+ proposalUuid: "<proposal-uuid>",
189
+ reviewNote: "Requirements changed — original approach no longer viable."
190
+ })
191
+ ```
192
+
193
+ 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.
194
+
195
+ ### Workflow B: Task Verification
196
+
197
+ #### B1: Review the Submitted Task
198
+
199
+ ```
200
+ chorus_get_task({ taskUuid: "<task-uuid>" })
201
+ ```
202
+
203
+ Check: developer's work summary, acceptance criteria, self-check results.
204
+
205
+ #### B2: Read Comments and Work Reports
206
+
207
+ ```
208
+ chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
209
+ ```
210
+
211
+ #### B2.5: Independent Review
212
+
213
+ Spawn `chorus-task-reviewer` per the [Review Strategy](#review-strategy) above — use the blocking `subagent` tool (it waits). After it completes, read its VERDICT:
214
+
215
+ - **VERDICT: PASS** or **PASS WITH NOTES** → proceed to B3 (mark AC) and B4 (verify).
216
+ - **VERDICT: FAIL** → skip to B4 and **reopen** the task. Do NOT mark AC as passed.
217
+
218
+ #### B2.6: Final Code-Review Gateway (after an Idea's LAST task is verified)
219
+
220
+ When the task you just verified is the **last** task of its idea-rooted proposal, run the ship-time code-review gateway before the Idea's code is considered shipped. The the extension injects a reminder to spawn `chorus-code-reviewer` (gated by `enableCodeReviewer`, default on). Spawn it per the [Review Strategy](#review-strategy) — via the blocking `subagent` tool, passing the `ideaUuid` + round number. It reviews the Idea's **aggregate** code change across all its tasks — cross-task integration, architecture/convention consistency, security, regression/performance, feature-level test coverage — dimensions a single-task review cannot see — and posts one `VERDICT` comment on the **idea**.
221
+
222
+ - **VERDICT: PASS** / **PASS WITH NOTES** → the feature may ship.
223
+ - **VERDICT: FAIL** → do not reopen the verified tasks; instead add new fix tasks to the approved proposal via `/skill:quick-dev` (`chorus_create_tasks` with `proposalUuid` set to the current approved proposal so the fix tasks attach to it). Group related small BLOCKERs by default; split only materially large or independently testable fixes. Require AC self-check, independent task review, and admin verification for every fix task. Re-run aggregate review only after every fix is successfully `done`; a failed or cancelled fix stops the loop and escalates. Bounded by `CHORUS_MAX_CODE_REVIEW_ROUNDS` (env, default 3; 0 = unlimited).
224
+
225
+ > **Advisory / behavioral** — the gateway does not change the Idea's stored status; the admin honors its verdict. Run it **before** writing any idea-completion report (the report must not be written while a `FAIL` is outstanding).
226
+
227
+ #### B3: Mark Acceptance Criteria
228
+
229
+ Review and mark each criterion:
230
+
231
+ ```
232
+ chorus_mark_acceptance_criteria({
233
+ taskUuid: "<task-uuid>",
234
+ criteria: [
235
+ { uuid: "<criterion-uuid>", status: "passed" },
236
+ { uuid: "<criterion-uuid>", status: "passed" },
237
+ { uuid: "<criterion-uuid>", status: "failed", evidence: "Missing edge case handling" }
238
+ ]
239
+ })
240
+ ```
241
+
242
+ #### B4: Verify or Reopen
243
+
244
+ **Verify (all required AC passed):**
245
+
246
+ ```
247
+ chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
248
+ ```
249
+
250
+ This moves the task to `done`. **Important:** verifying may unblock downstream tasks. Check:
251
+
252
+ ```
253
+ chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })
254
+ ```
255
+
256
+ If new tasks are unblocked, assign them or notify developers.
257
+
258
+ **Reopen (needs fixes):**
259
+
260
+ ```
261
+ chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
262
+
263
+ chorus_add_comment({
264
+ targetType: "task",
265
+ targetUuid: "<task-uuid>",
266
+ content: "Reopened: Missing error handling for user-not-found edge case."
267
+ })
268
+ ```
269
+
270
+ The task returns to `in_progress`. All acceptance criteria are reset.
271
+
272
+ #### B5: Close / Delete Tasks
273
+
274
+ ```
275
+ # Close (preserves history)
276
+ chorus_admin_close_task({ taskUuid: "<task-uuid>" })
277
+
278
+ # Delete (permanent, use sparingly)
279
+ chorus_admin_delete_task({ taskUuid: "<task-uuid>" })
280
+ ```
281
+
282
+ ### Workflow C: Project & Idea Management
283
+
284
+ #### Create Project
285
+
286
+ ```
287
+ chorus_get_project_groups() # List available groups first
288
+ chorus_admin_create_project({
289
+ name: "My Project",
290
+ description: "Project goals...",
291
+ groupUuid: "<optional-group-uuid>"
292
+ })
293
+ ```
294
+
295
+ #### Manage Project Groups
296
+
297
+ ```
298
+ chorus_admin_create_project_group({ name: "Mobile Apps", description: "All mobile projects" })
299
+ chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: "<uuid>" })
300
+ chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: null }) # Ungroup
301
+ chorus_admin_delete_project_group({ groupUuid: "<uuid>" }) # Projects become ungrouped
302
+ ```
303
+
304
+ #### Close / Delete Ideas
305
+
306
+ ```
307
+ chorus_admin_close_idea({ ideaUuid: "<idea-uuid>" })
308
+ chorus_admin_delete_idea({ ideaUuid: "<idea-uuid>" })
309
+ ```
310
+
311
+ > **Note:** Creating ideas is a PM tool (`chorus_pm_create_idea`). See `/idea`.
312
+
313
+ #### Document Management
314
+
315
+ ```
316
+ chorus_admin_delete_document({ documentUuid: "<doc-uuid>" })
317
+ chorus_pm_update_document({ documentUuid: "<doc-uuid>", content: "Updated..." })
318
+ ```
319
+
320
+ ---
321
+
322
+ ## Daily Admin Routine
323
+
324
+ 1. **Check in** — `chorus_checkin()`
325
+ 2. **Review activity** — `chorus_get_activity()` for recent events
326
+ 3. **Process proposals** — Review and approve/reject pending proposals
327
+ 4. **Verify tasks** — Review and verify/reopen tasks in `to_verify`
328
+ 5. **Create new ideas** — If the human has new requirements
329
+ 6. **Check project health** — Stale tasks? Blocked items? Orphaned ideas?
330
+
331
+ ---
332
+
333
+ ## Tips
334
+
335
+ - **Review thoroughly** — Don't rubber-stamp proposals; check quality
336
+ - **Give actionable feedback** — When rejecting, explain specifically what to fix
337
+ - **Verify against criteria** — Check acceptance criteria, not just the summary
338
+ - **Manage scope** — Close ideas and tasks that are no longer relevant
339
+ - **Unblock the team** — Prioritize proposal reviews to keep PM and Developer work flowing
340
+ - **Use delete sparingly** — Prefer closing over deleting; closing preserves history
341
+ - **Document decisions** — Use comments to explain approval/rejection reasoning
342
+ - **Verify between waves** — In parallel-subagent mode, verify tasks to `done` between waves to unblock downstream dependencies (and `subagent_manage close` finished workers to release their slots)
343
+
344
+ ---
345
+
346
+ ## Governance Principles
347
+
348
+ 1. **Quality over speed** — A rejected proposal now saves rework later
349
+ 2. **Actionable feedback** — Every rejection should include specific fixes
350
+ 3. **Criteria-based verification** — Verify against acceptance criteria, not just subjective impression
351
+ 4. **Scope discipline** — Close what's no longer needed, don't let orphaned items pile up
352
+ 5. **Unblock others** — Your reviews are the bottleneck; prioritize them
353
+ 6. **Preserve history** — Close > Delete; comments > silent actions
354
+ 7. **Document reasoning** — Future agents will read your comments to understand decisions
355
+
356
+ ---
357
+
358
+ ## Next
359
+
360
+ - For platform overview and shared tools, see `/chorus`
361
+ - For Idea elaboration (before proposals), see `/idea`
362
+ - For Proposal creation (what you're reviewing), see `/proposal`
363
+ - For Developer workflow (what you're verifying), see `/develop`