@chorus-aidlc/chorus-openclaw-plugin 0.4.0 → 0.5.3

package/skills/quick-dev/SKILL.md

@@ -1,15 +1,20 @@
 ---
 name: quick-dev
 description: Quick Task workflow — skip Idea→Proposal, create tasks directly, execute, and verify.
+license: AGPL-3.0
 metadata:
-  openclaw:
-    emoji: "⚡"
+  author: chorus
+  version: "0.9.4"
+  category: project-management
+  mcp_server: chorus
 ---
 
 # Quick Dev Skill
 
 Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) and create tasks directly. Ideal for small, well-understood work. The goal is for agents to **autonomously record their development work and verify task completion** through structured acceptance criteria.
 
+> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `chorus__` prefix on OpenClaw (e.g. `chorus__chorus_create_tasks`). Bare names are used below for readability — prepend `chorus__` when invoking. See `/chorus` for the full rule.
+
 ---
 
 ## Overview
@@ -39,9 +44,9 @@ For complex work, use `/idea` + `/proposal` instead.
 
 ## Pre-Flight: Admin Self-Verify Check
 
-**Before creating tasks**, if you have the `admin_agent` role, ask the user:
+**Before creating tasks**, if `chorus_checkin().agent.permissions.task` includes `"admin"`, ask the user (as a **plain-text prompt** — OpenClaw has no `AskUserQuestion`):
 
-> "I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify?"
+> "I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify? Reply 'self' or 'other'."
 
 This matters because admin agents can call `chorus_admin_verify_task` to close the loop autonomously. If the user approves self-verification, you can complete the entire create → develop → verify cycle without human intervention. Record the decision and apply it in Step 7.
 
@@ -65,7 +70,7 @@ This matters because admin agents can call `chorus_admin_verify_task` to close t
 
 ### Step 1: Create a Quick Task
 
-**Always include `acceptanceCriteriaItems`** — these are the foundation for self-checking in Step 6. Write specific, testable criteria that you can objectively verify after development. Vague AC like "works correctly" defeats the purpose; prefer "returns 200 on GET /api/foo with valid token".
+**`acceptanceCriteriaItems` is required** — `chorus_create_tasks` rejects any task without at least one non-blank criterion (and rejects the whole batch if any task is missing them). These are also the foundation for self-checking in Step 6. Write specific, testable criteria that you can objectively verify after development. Vague AC like "works correctly" defeats the purpose; prefer "returns 200 on GET /api/foo with valid token".
 
 ```
 chorus_create_tasks({
@@ -95,7 +100,7 @@ chorus_claim_task({ taskUuid: "<task-uuid>" })
 
 ### Step 3: Edit Details (if needed)
 
-Use `chorus_update_task` to refine the task after creation. **If you skipped AC in Step 1, add them now** — you will need them for self-check later. Also update AC when your understanding of the task changes during development.
+Use `chorus_update_task` to refine the task after creation. Tasks always have AC (creation requires them), but **update them when your understanding changes during development**. Passing `acceptanceCriteriaItems` **replaces** the task's criteria with the provided non-empty set; omit the field to leave them unchanged (it cannot be used to clear AC).
 
 ```
 chorus_update_task({
@@ -115,12 +120,18 @@ chorus_update_task({
 chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })
 ```
 
+**Sub-agents:** create your own session first (manual on OpenClaw — see `/develop`), then pass `sessionUuid` for attribution:
+```
+chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress", sessionUuid: "<session-uuid>" })
+```
+
 ### Step 5: Report Progress
 
 ```
 chorus_report_work({
   taskUuid: "<task-uuid>",
-  report: "Fixed Safari cookie issue:\n- Root cause: SameSite=Strict incompatible with redirect\n- Changed to SameSite=Lax\n- Commit: abc1234"
+  report: "Fixed Safari cookie issue:\n- Root cause: SameSite=Strict incompatible with redirect\n- Changed to SameSite=Lax\n- Commit: abc1234",
+  sessionUuid: "<session-uuid>"
 })
 ```
 
@@ -145,7 +156,7 @@ chorus_submit_for_verify({
 })
 ```
 
-**Admin self-verification:** If you have the `admin_agent` role and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
+**Admin self-verification:** If you have `task: ["admin"]` in `permissions` and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
 
 ```
 chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
@@ -153,16 +164,29 @@ chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
 
 This completes the full autonomous cycle: create → develop → verify → done.
 
+> **Optional independent review:** for non-trivial quick tasks you may still run the `/task-reviewer` skill in a spawned sub-agent (`sessions_spawn` with a task telling it to run `/task-reviewer` against the taskUuid, then wait for the VERDICT) or do a focused read-only self-review before verifying — same pattern as `/develop` Step 8.5. There is no PostToolUse hook on OpenClaw, so do this inline if you want it.
+
+---
+
+## Session Integration
+
+Quick Tasks support sub-agent execution just like proposal-based tasks. **Session lifecycle is manual on OpenClaw** (no SubagentStart/heartbeat/cleanup hooks):
+
+- **Main agent**: create quick tasks, work them yourself, or hand task UUIDs to sub-agents
+- **Sub-agents**: create your own session (`chorus_create_session`), checkin/checkout per task, pass `sessionUuid` to `chorus_update_task` / `chorus_report_work`, and close the session on exit — see `/develop` for the full manual protocol
+
+> OpenClaw has no Agent Teams / `TeamCreate` primitive; if you need to run several quick tasks, work them sequentially as the main agent (or dispatch generic sub-agents one at a time).
+
 ---
 
 ## Tips
 
 - Keep Quick Tasks small — if you need more than 2-3 tasks, consider using `/proposal`
-- **Always write acceptance criteria at creation time** — they are your self-check contract. Specific, testable AC enables autonomous verification and makes the entire workflow self-contained
+- **Acceptance criteria are required at creation time** — `chorus_create_tasks` rejects tasks without them. They are your self-check contract; specific, testable AC enables autonomous verification and makes the entire workflow self-contained
 - Use `chorus_update_task` to refine tasks (including AC) after creation rather than deleting and recreating
 - Pass `proposalUuid` to attach follow-up or gap-filling tasks to an existing proposal — this keeps related work grouped in the same project context and DAG
 - Quick Tasks show up in the same project task list and DAG as proposal-based tasks
-- Admin agents can run the full lifecycle autonomously (create → develop → self-verify) — but always confirm with the user first
+- Admin agents can run the full lifecycle autonomously (create → develop → self-verify) — but always confirm with the user first (plain-text prompt)
 
 ---
 

package/skills/review/SKILL.md

@@ -1,15 +1,20 @@
 ---
 name: review
-description: Chorus Review workflow — approve/reject proposals, verify tasks, and manage governance.
+description: Chorus Review workflow — approve/reject proposals, verify tasks, and manage project governance.
+license: AGPL-3.0
 metadata:
-  openclaw:
-    emoji: "✅"
+  author: chorus
+  version: "0.9.4"
+  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.
 
+> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `chorus__` prefix on OpenClaw (e.g. `chorus__chorus_admin_verify_task`). Bare names are used below for readability — prepend `chorus__` when invoking. See `/chorus` for the full rule.
+
 ---
 
 ## Overview
@@ -19,7 +24,7 @@ Admin Agent has **full access to all Chorus operations**. You are the **human pr
 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, manage groups, organize work
+- **Project governance** — create projects/ideas, manage groups, close/delete entities
 
 ---
 
@@ -30,28 +35,45 @@ Key responsibilities:
 | Tool | Purpose |
 |------|---------|
 | `chorus_admin_create_project` | Create a new project (optional `groupUuid` for group assignment) |
-| `chorus_admin_create_project_group` | Create a new project group for organizing projects |
 | `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):**
 
-**All PM tools** (`chorus_pm_*`, `chorus_*_idea`) and **all Developer tools** (`chorus_claim_task`, `chorus_report_work`, etc.) are also available to Admin.
+| 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`
 
 ---
 
-## SSE Wake Events
-
-The OpenClaw plugin listens for SSE events relevant to admin review:
+## Review Strategy
 
-| SSE Event | Trigger | Agent Action |
-|-----------|---------|--------------|
-| `task_assigned` | A task is assigned to you | Wake and review/start work |
-| `mentioned` | You are @mentioned in a comment | Wake and respond |
-| `proposal_approved` / `proposal_rejected` | Proposal status changed | Informational — check new tasks or feedback |
+When reviewing proposals or tasks, get an independent VERDICT before approving/verifying. On OpenClaw there is **no PostToolUse hook** to remind you — invoke the review yourself, inline.
 
-When tasks are submitted for verification or proposals are submitted for review, the admin agent is woken to process them.
+1. **Preferred — spawn a reviewer sub-agent.** Use the OpenClaw `sessions_spawn` tool to spawn a sub-agent whose `task` tells it to **invoke the `/proposal-reviewer` skill** (for proposals) or the `/task-reviewer` skill (for tasks) — both bundled with this plugin — against the entity. Wait for it (poll the `subagents` tool or use `sessions_yield` — do NOT detach; you must have the VERDICT before proceeding). The sub-agent inherits the plugin skills, so the reviewer skill is available to it; it posts a VERDICT comment with detailed findings. Example task prompt: `Run the /proposal-reviewer skill to review proposalUuid <uuid>; post your VERDICT comment when done.`
+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:
+   - **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?** The sub-agent 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 (step 5).
+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.
+5. **Fallback — review it yourself (no `sessions_spawn` on the host).** If spawning is unavailable (disabled by policy, or the spawn fails), perform the review yourself as a **focused, read-only pass** using the quality checklists in the workflows below: read the entity, its comments, and the relevant documents/code, run read-only test/build commands where applicable, and do NOT modify anything. Then record your VERDICT via `chorus_add_comment` ending with a `VERDICT:` line (PASS / PASS WITH NOTES / FAIL), classifying every finding as BLOCKER or NOTE. The `/proposal-reviewer` and `/task-reviewer` skills are the authoritative checklists for this manual pass — read them and follow their procedure.
 
 ---
 
@@ -90,10 +112,12 @@ Prioritize: **Proposals first** (they unblock PM and Developer work), then task
 #### A1: Read the Proposal
 
 ```
-chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
 ```
 
-This returns: title, description, input ideas, **document drafts** (PRD, tech design), **task drafts** (with descriptions and acceptance criteria).
+`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
 
@@ -121,6 +145,10 @@ This returns: title, description, input ideas, **document drafts** (PRD, tech de
 chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
 ```
 
+#### A3.5: Independent Review
+
+Get a VERDICT per the [Review Strategy](#review-strategy) above — spawn a sub-agent via `sessions_spawn` and have it run the `/proposal-reviewer` skill (wait for it), otherwise review yourself as a read-only pass and post the VERDICT. Read its VERDICT comment before proceeding.
+
 #### A4: Approve or Reject
 
 **Approve:**
@@ -140,16 +168,32 @@ When approved:
 
 **Reject:**
 
-Rejection is done by adding a comment with specific feedback. The PM agent will see the comment and can revise the proposal.
-
 ```
+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: "Rejecting — specific feedback:\n1. Add error scenarios to PRD\n2. Task 3 AC should include performance benchmarks"
+  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
@@ -158,7 +202,7 @@ chorus_add_comment({
 chorus_get_task({ taskUuid: "<task-uuid>" })
 ```
 
-Check: developer's work summary, acceptance criteria, self-check results (devStatus and devEvidence on each criterion).
+Check: developer's work summary, acceptance criteria, self-check results.
 
 #### B2: Read Comments and Work Reports
 
@@ -166,7 +210,12 @@ Check: developer's work summary, acceptance criteria, self-check results (devSta
 chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
 ```
 
-Work reports are recorded as comments — look for implementation details, files changed, commits, and PRs.
+#### B2.5: Independent Review
+
+Get a VERDICT per the [Review Strategy](#review-strategy) above — spawn a sub-agent via `sessions_spawn` and have it run the `/task-reviewer` skill (wait for it), otherwise review yourself as a read-only pass and post the VERDICT. After it completes, read its VERDICT:
+
+- **VERDICT: PASS** or **PASS WITH NOTES** → proceed to B3 (mark AC) and B4 (verify).
+- **VERDICT: FAIL** → skip to B4 and **reopen** the task. Do NOT mark AC as passed.
 
 #### B3: Mark Acceptance Criteria
 
@@ -199,19 +248,31 @@ chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })
 
 If new tasks are unblocked, assign them or notify developers.
 
-**Request rework:**
-
-If the task needs fixes, add a comment with specific feedback:
+**Reopen (needs fixes):**
 
 ```
+chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
+
 chorus_add_comment({
   targetType: "task",
   targetUuid: "<task-uuid>",
-  content: "Needs rework: Missing error handling for user-not-found edge case."
+  content: "Reopened: Missing error handling for user-not-found edge case."
 })
 ```
 
-### Workflow C: Project Management
+The task returns to `in_progress`. All acceptance criteria are reset.
+
+#### B5: Close / Delete Tasks
+
+```
+# Close (preserves history)
+chorus_admin_close_task({ taskUuid: "<task-uuid>" })
+
+# Delete (permanent, use sparingly)
+chorus_admin_delete_task({ taskUuid: "<task-uuid>" })
+```
+
+### Workflow C: Project & Idea Management
 
 #### Create Project
 
@@ -228,14 +289,25 @@ chorus_admin_create_project({
 
 ```
 chorus_admin_create_project_group({ name: "Mobile Apps", description: "All mobile projects" })
+chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: "<uuid>" })
+chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: null })  # Ungroup
+chorus_admin_delete_project_group({ groupUuid: "<uuid>" })  # Projects become ungrouped
+```
+
+#### Close / Delete Ideas
+
+```
+chorus_admin_close_idea({ ideaUuid: "<idea-uuid>" })
+chorus_admin_delete_idea({ ideaUuid: "<idea-uuid>" })
 ```
 
-#### Assign Tasks
+> **Note:** Creating ideas is a PM tool (`chorus_pm_create_idea`). See `/idea`.
 
-Use the PM tool to assign tasks to specific agents:
+#### Document Management
 
 ```
-chorus_pm_assign_task({ taskUuid: "<task-uuid>", assigneeUuid: "<agent-uuid>", assigneeType: "agent" })
+chorus_admin_delete_document({ documentUuid: "<doc-uuid>" })
+chorus_pm_update_document({ documentUuid: "<doc-uuid>", content: "Updated..." })
 ```
 
 ---
@@ -245,7 +317,7 @@ chorus_pm_assign_task({ taskUuid: "<task-uuid>", assigneeUuid: "<agent-uuid>", a
 1. **Check in** — `chorus_checkin()`
 2. **Review activity** — `chorus_get_activity()` for recent events
 3. **Process proposals** — Review and approve/reject pending proposals
-4. **Verify tasks** — Review and verify tasks in `to_verify`
+4. **Verify tasks** — Review and verify/reopen tasks in `to_verify`
 5. **Create new ideas** — If the human has new requirements
 6. **Check project health** — Stale tasks? Blocked items? Orphaned ideas?
 
@@ -254,11 +326,13 @@ chorus_pm_assign_task({ taskUuid: "<task-uuid>", assigneeUuid: "<agent-uuid>", a
 ## Tips
 
 - **Review thoroughly** — Don't rubber-stamp proposals; check quality
-- **Give actionable feedback** — When requesting changes, explain specifically what to fix
+- **Give actionable feedback** — When rejecting, explain specifically what to fix
 - **Verify against criteria** — Check acceptance criteria, not just the summary
+- **Manage scope** — Close ideas and tasks that are no longer relevant
 - **Unblock the team** — Prioritize proposal reviews to keep PM and Developer work flowing
+- **Use delete sparingly** — Prefer closing over deleting; closing preserves history
 - **Document decisions** — Use comments to explain approval/rejection reasoning
-- **Check downstream** — After verifying a task, check `chorus_get_unblocked_tasks` to see what was unblocked
+- **Verify between waves** — In sequential wave execution, verify tasks to `done` between waves to unblock downstream dependencies
 
 ---
 
@@ -267,9 +341,9 @@ chorus_pm_assign_task({ taskUuid: "<task-uuid>", assigneeUuid: "<agent-uuid>", a
 1. **Quality over speed** — A rejected proposal now saves rework later
 2. **Actionable feedback** — Every rejection should include specific fixes
 3. **Criteria-based verification** — Verify against acceptance criteria, not just subjective impression
-4. **Scope discipline** — Keep work focused on what was planned
+4. **Scope discipline** — Close what's no longer needed, don't let orphaned items pile up
 5. **Unblock others** — Your reviews are the bottleneck; prioritize them
-6. **Preserve history** — Comments and decisions help future agents understand reasoning
+6. **Preserve history** — Close > Delete; comments > silent actions
 7. **Document reasoning** — Future agents will read your comments to understand decisions
 
 ---

package/skills/task-reviewer/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: task-reviewer
+description: Adversarial verification of a submitted Chorus task against its AC and proposal documents — read the code, verify each criterion, run tests. Invoke after a task is submitted for verify; ends with a VERDICT comment.
+license: AGPL-3.0
+metadata:
+  author: chorus
+  version: "0.9.4"
+  category: project-management
+  mcp_server: chorus
+---
+
+# Task Reviewer Skill
+
+You have been asked to **verify a submitted Chorus task**. Your job is **not** to confirm the implementation works — it's to find where it doesn't match the requirements.
+
+> **How you were invoked.** A developer/orchestrator agent spawned you (via the OpenClaw `sessions_spawn` tool) and told you to run this skill against a specific `taskUuid`. Read it from your task prompt. When you finish, you post one `VERDICT:` comment back to the task — that comment IS your deliverable; the parent reads it.
+
+> **Tool namespace.** Chorus tools come from the connected MCP server under a `chorus__` prefix (e.g. `chorus__chorus_get_task`, `chorus__chorus_add_comment`). Bare names are used below for readability — prepend `chorus__` when invoking.
+
+## Hard rules (READ-ONLY, except read-only Bash)
+
+- **You CANNOT edit, write, or create files** in the project directory. Do NOT modify any entity except posting your one review comment.
+- **Bash is READ-ONLY:** only test/build/lint commands and inspection (`cat`/`head`/`tail`/`wc`/`diff`, `grep`/`rg`/`ls`/`find`, `git diff`/`git log`/`git show`). **Strictly forbidden:** `git add`/`commit`/`push`/`checkout`/`reset`; `rm`/`mv`/`cp`/`echo >`/`tee`/`sed -i`; package installs (`npm install`, `pnpm add`, `pip install`); `curl -X POST/PUT/DELETE`.
+- **Keep your comment under 800 characters.** PASS items: names only. NOTE items: one-line. BLOCKER items: command + output + evidence.
+- **Classify every finding** as BLOCKER (blocks correctness: build/test failure, AC not implemented, semantic contradiction) or NOTE (non-blocking: pseudocode mismatch, wording difference, style).
+- **End with a single line beginning `VERDICT:`** — exactly one of `PASS`, `PASS WITH NOTES`, `FAIL`. Has BLOCKERs → FAIL. Only NOTEs → PASS WITH NOTES. Nothing → PASS.
+- **Round 2+:** focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs.
+- **Budget rule:** if running low on turns/time, STOP reading files AND stop running bash/tests immediately and post your current findings via `chorus_add_comment`. Incomplete findings posted beat no comment.
+- **Do NOT confirm — find what's wrong.** Batch data gathering, then one final comment.
+
+You have two failure patterns. **Verification avoidance**: reading code, narrating what you would test, writing "PASS," never actually running anything. **Being seduced by the first 80%**: passing tests + clean code, not noticing AC are only superficially met, the implementation diverges from proposal documents, or edge cases silently fail. The developer is an LLM — its self-tests may be circular (testing mocks, not behavior).
+
+## What you receive
+
+A `taskUuid` (in your task prompt). Fetch the task, its AC, and the proposal documents, then independently verify the implementation.
+
+## Review procedure
+
+**Efficiency rule:** Gather ALL context in Steps 1–2 before verifying. Batch tool calls — do not alternate between fetching and concluding.
+
+**Step 1: Gather context**
+```
+chorus_get_task({ taskUuid: "<uuid>" })
+chorus_get_comments({ targetType: "task", targetUuid: "<uuid>" })
+chorus_get_proposal({ proposalUuid: "<from-task>", section: "documents" })
+chorus_get_document({ documentUuid: "<doc-uuid>" })
+```
+
+**Step 2: Read the code.** Use Glob/Grep to find relevant files, then read them. Do NOT rely on the developer's summary — read the code yourself.
+
+**Step 3: Verify each AC independently.** For EACH acceptance criterion: (1) read what it requires, word by word; (2) find the code that implements it; (3) run a verification command if possible; (4) determine PASS or FAIL with evidence. Do NOT batch AC as "all look good." Check each one.
+
+**Step 4: Cross-reference with proposal documents.** Does the PRD mention fields, behaviors, or error scenarios not covered by any AC? Does the tech design specify contracts the code doesn't follow?
+
+**Step 5: Run tests/build if available.** A broken build or failing tests is an automatic FAIL. Test results are context, not proof — verify AC independently after noting results.
+
+**Step 6: Adversarial probes.** Pick 2–3 probes that fit the task: boundary values, missing fields, error paths, concurrency. Run them — don't just describe them.
+
+**Hallucination check:** Flag anything that looks LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names, or any external detail the developer likely wrote from memory.
+
+## Finding classification
+
+**BLOCKER** — blocks correctness: AC not actually implemented; build or test failures; implementation diverges from proposal documents (semantic contradiction); edge cases causing runtime errors; missing error handling for required scenarios.
+
+**NOTE** — does not block: pseudocode signature mismatch; wording differences between docs and comments; style/naming suggestions; non-semantic inconsistencies.
+
+Rules: Pseudocode inconsistencies → always NOTE. Cross-document wording differences → always NOTE. Only functional/behavioral issues → BLOCKER. VERDICT: has BLOCKERs → FAIL; only NOTEs → PASS WITH NOTES; nothing → PASS.
+
+## Round awareness
+
+- **Round 1**: full review, normal strictness.
+- **Round 2+**: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on unflagged areas. If all previous BLOCKERs resolved → VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain). Re-read only the specific files and re-run only the specific tests tied to previous BLOCKERs — do not re-scan unrelated code or rerun the full suite. Trusting the developer's diff summary without targeted re-verification is the "verification avoidance" anti-pattern.
+
+## Recognize your own rationalizations
+
+- "The code looks correct based on my reading" — reading is not verification. Run it.
+- "The developer's tests already pass" — the developer is an LLM. Verify independently.
+- "This AC is probably met" — probably is not verified. Find the specific code and check.
+- "The API call looks right" — for external API/SDK calls, request execution evidence (run logs, test output, errors). If none and you cannot run it, flag as NOTE.
+
+## Output format (required)
+
+```
+### Review Summary
+
+**PASS (N):** AC-1 name, AC-2 name, ...
+
+**NOTE (M):**
+- Note-1: [one-line description]
+
+**BLOCKER (K):**
+### Blocker-1: name
+**Command run:** [exact command executed]
+**Output observed:** [actual output — copy-paste, not paraphrased]
+**Evidence:** [file paths, line numbers]
+**Expected:** [expected behavior]
+**Actual:** [actual behavior]
+
+VERDICT: PASS / PASS WITH NOTES / FAIL
+```
+
+PASS items: names only. NOTE items: one-line. BLOCKER items: full command/output/evidence. Total under 800 chars. No preamble. The final line MUST start with `VERDICT:`.
+
+## Post results
+
+Post the full review as a single comment, then you are done:
+```
+chorus_add_comment({
+  targetType: "task",
+  targetUuid: "<task-uuid>",
+  content: "<your review>"
+})
+```