@chorus-aidlc/chorus 0.9.2 → 0.9.4

package/.next/standalone/public/skill/idea-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Idea workflow — claim ideas, run elaboration rounds, and p
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.3.1"
+  version: "0.9.4"
   category: project-management
   mcp_server: chorus
 ---
@@ -44,10 +44,10 @@ All post-elaboration progress (planning, building, verifying, done) is **derived
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_pm_start_elaboration` | Start an elaboration round with structured questions |
-| `chorus_pm_validate_elaboration` | Validate answers (resolve or create follow-up round) |
+| `chorus_pm_start_elaboration` | Generate an elaboration round (first, follow-up, or appended-after-resolution) |
+| `chorus_pm_validate_elaboration` | Mark the whole elaboration complete (requires `idea:admin`; requires human confirmation first) |
 | `chorus_pm_skip_elaboration` | Skip elaboration for trivially clear Ideas |
-| `chorus_answer_elaboration` | Submit answers for an elaboration round |
+| `chorus_answer_elaboration` | Submit answers for an elaboration round (`roundUuid` optional — auto-locates the active round) |
 | `chorus_get_elaboration` | Get full elaboration state (rounds, questions, answers) |
 
 **Shared tools** (checkin, query, comment, search, notifications): see `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`)
@@ -123,8 +123,8 @@ If the Idea is fuzzy and you'd struggle to enumerate concrete multi-choice quest
 
 When the brainstorm skill returns, you own the lifecycle decision (the brainstorm skill deliberately leaves it to you):
 
-- If the synthesized round answers cover everything → call `chorus_pm_validate_elaboration` with `issues: []` to resolve elaboration.
-- If gaps remain → call `chorus_pm_validate_elaboration` with `issues + followUpQuestions` to start a structured Round 2. Pick the depth yourself — do NOT re-prompt the user.
+- If the synthesized round answers cover everything → obtain human confirmation, then call `chorus_pm_validate_elaboration` to resolve the elaboration. (Resolve needs `idea:admin` — see Step 5.6 if your key is `pm_agent`-preset.)
+- If gaps remain → call `chorus_pm_start_elaboration` again to open a structured Round 2. Pick the depth yourself — do NOT re-prompt the user.
 
 Either outcome ends Step 4.5; skip Step 5.
 
@@ -145,6 +145,12 @@ chorus_pm_skip_elaboration({
 
 #### Standard/Complex Ideas (run elaboration)
 
+> **Elaboration is a loop, not a straight line.** Steps 2–5 below are **one round**. Keep looping back to `chorus_pm_start_elaboration` (a new round) until every open question is settled, then resolve **once** in Step 6. You re-enter the loop whenever:
+> - the answers to a round **derive new questions** or surface a contradiction/gap, **or**
+> - at the resolve gate (Step 5d / Step 6) the **human raises a new concern or correction**.
+>
+> Each new round is just another `chorus_pm_start_elaboration` call — there is no separate "follow-up" flag, and you do not resolve until the loop is genuinely done. Round cap is 10.
+
 1. **Determine depth** based on idea complexity:
    - `"minimal"` — 2-4 questions (small features, minor enhancements)
    - `"standard"` — 5-10 questions (typical new features)
@@ -205,9 +211,11 @@ chorus_pm_skip_elaboration({
    - **Select an option + add a note**: `selectedOptionId: "a", customText: "additional context"`
    - **Choose "Other" (free text)**: `selectedOptionId: null, customText: "your answer"` — customText is required when no option is selected
 
+   > `roundUuid` is **optional** on `chorus_answer_elaboration`. Omit it and the service auto-locates the Idea's single active (`pending_answers`) round. Pass it explicitly only when you need to target a specific round.
+
 5. **Review answers and confirm with the owner (@mention flow):**
 
-   After answers are submitted, **@mention the answerer** (typically the agent's owner) with a summary of your understanding. This prevents misinterpretation before you validate.
+   After answers are submitted, **@mention the answerer** (typically the agent's owner) with a summary of your understanding. This prevents misinterpretation before you resolve.
 
    a. **Get owner info** from checkin response (`agent.owner`) or search:
       ```
@@ -225,39 +233,32 @@ chorus_pm_skip_elaboration({
 
    c. **Wait for confirmation** via comments.
 
-   d. **Based on the response:**
-      - **Confirmed** — Proceed to validate with empty issues
-      - **Additions/corrections** — Incorporate feedback, optionally start a follow-up round
-      - **Unclear** — Ask clarifying questions via another comment
+   d. **Based on the response — this is the loop decision point:**
+      - **Confirmed, nothing left to discuss** — Treat this as the human confirmation required to resolve; proceed to Step 6 and call `chorus_pm_validate_elaboration`.
+      - **Human raises a new concern / correction / question** — Do **NOT** resolve. Loop back: open a **new round** with `chorus_pm_start_elaboration` capturing the new questions, collect answers (Steps 2–5 again), and re-confirm. Repeat until the human has no remaining concerns.
+      - **The answers themselves derived new questions or a contradiction** — Same as above: loop back to `chorus_pm_start_elaboration` for another round before resolving.
+      - **Unclear** — Ask clarifying questions via another comment, then continue the loop.
 
-6. **Validate the elaboration:**
+6. **Resolve the elaboration (the single commit gate — only when the loop is done):**
 
-   `chorus_pm_validate_elaboration` is the **single commit gate for the entire elaboration phase**, NOT a per-round close. Calling it with `issues: []` resolves the whole elaboration (sets `idea.elaborationStatus = "resolved"`); calling it with `issues + followUpQuestions` opens a new round while keeping elaboration in progress. Do not call validate after every round — call it once when you believe elaboration is done, or when you want to start a follow-up round.
+   Resolving marks the **whole elaboration phase** complete — it sets `idea.elaborationStatus = "resolved"` (Idea → `elaborated`), which is the gating signal that lets a downstream Proposal be submitted. It is an **Idea-level** action (takes only `ideaUuid`, does not target a round). Resolve **once**, only after the Step 5d loop has fully settled — every derived question answered and the human has no remaining concerns. If anything is still open, go back to `chorus_pm_start_elaboration` instead of resolving.
 
-   ```
-   chorus_pm_validate_elaboration({
-     ideaUuid: "<idea-uuid>",
-     roundUuid: "<round-uuid>",
-     issues: [],
-     followUpQuestions: []
-   })
-   ```
+   > **Precondition:** resolve requires the Idea to have at least one round and **every** round to be fully answered (none left in `pending_answers`). If a round still has open questions, answer it (or it'll be rejected).
 
-   If issues are found (contradictions, ambiguities, incomplete answers), include them in `issues` and provide `followUpQuestions` for a new round:
+   > **⚠️ Human confirmation required.** Outside YOLO automation you MUST obtain explicit human confirmation before resolving. The "Confirmed" reply in step 5d above counts as that confirmation. Never resolve on your own judgment alone.
+
+   > **Permission (N1): `chorus_pm_validate_elaboration` requires `idea:admin`.** The `pm_agent` preset only grants `idea:write`, so a PM-preset agent **cannot** resolve — it must hand off to an `admin_agent`-preset agent (or an admin-preset API key) to perform the resolve. If your key lacks `idea:admin`, surface this to the human and request the handoff instead of failing silently.
+
+   > **Assignee precondition (N2):** the resolving actor must be the Idea's **assignee**. A separate human reviewer resolving a PM-owned Idea therefore needs **both** `idea:admin` **and** to be assigned the Idea (claim/reassign it first). Admin permission alone is not enough.
 
    ```
    chorus_pm_validate_elaboration({
-     ideaUuid: "<idea-uuid>",
-     roundUuid: "<round-uuid>",
-     issues: [
-       { questionId: "q1", type: "ambiguity", description: "Role-based access selected but no roles defined" }
-     ],
-     followUpQuestions: [
-       { id: "fq1", text: "Which specific roles should have access?", category: "functional", options: [...] }
-     ]
+     ideaUuid: "<idea-uuid>"
    })
    ```
 
+   **Want a follow-up round instead of resolving?** Just call `chorus_pm_start_elaboration` again — there is no separate "open a round" flag. It works while still `elaborating` (a normal follow-up round) and, after you've already resolved, as an **appended round** (`isAppended: true`) that keeps the Idea `elaborated` and never blocks an in-flight Proposal. Per-question issue tagging no longer exists.
+
 7. **Check elaboration status** at any time:
    ```
    chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })
@@ -267,8 +268,6 @@ chorus_pm_skip_elaboration({
 
 **Question categories:** `functional`, `non_functional`, `business_context`, `technical_context`, `user_scenario`, `scope`
 
-**Validation issue types:** `contradiction`, `ambiguity`, `incomplete`
-
 ---
 
 ## Tips
@@ -277,7 +276,7 @@ chorus_pm_skip_elaboration({
 - Elaboration improves Proposal quality — prefer not to skip it unless the requirements are trivially clear
 - Use your IDE's interactive prompt mechanism if available for user-facing questions; otherwise present options as text
 - Record decisions made in conversation as elaboration rounds for auditability
-- Consider @mentioning the owner to confirm understanding before validating
+- Consider @mentioning the owner to confirm understanding before resolving
 
 ---
 

package/.next/standalone/public/skill/package.json

@@ -1,6 +1,6 @@
 {
   "name": "chorus-skill",
-  "version": "0.3.1",
+  "version": "0.9.3",
   "description": "Chorus AI Agent collaboration platform skill. Supports PM, Developer, and Admin roles via MCP tools for the Idea-Proposal-Task workflow.",
   "author": "chorus",
   "license": "AGPL-3.0",
@@ -23,7 +23,12 @@
       "idea-chorus/SKILL.md": "/skill/idea-chorus/SKILL.md",
       "proposal-chorus/SKILL.md": "/skill/proposal-chorus/SKILL.md",
       "develop-chorus/SKILL.md": "/skill/develop-chorus/SKILL.md",
-      "review-chorus/SKILL.md": "/skill/review-chorus/SKILL.md"
+      "review-chorus/SKILL.md": "/skill/review-chorus/SKILL.md",
+      "quick-dev-chorus/SKILL.md": "/skill/quick-dev-chorus/SKILL.md",
+      "brainstorm-chorus/SKILL.md": "/skill/brainstorm-chorus/SKILL.md",
+      "proposal-reviewer-chorus/SKILL.md": "/skill/proposal-reviewer-chorus/SKILL.md",
+      "task-reviewer-chorus/SKILL.md": "/skill/task-reviewer-chorus/SKILL.md",
+      "yolo-chorus/SKILL.md": "/skill/yolo-chorus/SKILL.md"
     },
     "requires": {
       "mcp": ["chorus"]
@@ -38,7 +43,10 @@
       "report work",
       "verify task",
       "approve proposal",
-      "project management"
+      "project management",
+      "yolo",
+      "review agent",
+      "verify"
     ]
   },
   "moltbot": {
@@ -48,7 +56,12 @@
       "idea-chorus/SKILL.md": "/skill/idea-chorus/SKILL.md",
       "proposal-chorus/SKILL.md": "/skill/proposal-chorus/SKILL.md",
       "develop-chorus/SKILL.md": "/skill/develop-chorus/SKILL.md",
-      "review-chorus/SKILL.md": "/skill/review-chorus/SKILL.md"
+      "review-chorus/SKILL.md": "/skill/review-chorus/SKILL.md",
+      "quick-dev-chorus/SKILL.md": "/skill/quick-dev-chorus/SKILL.md",
+      "brainstorm-chorus/SKILL.md": "/skill/brainstorm-chorus/SKILL.md",
+      "proposal-reviewer-chorus/SKILL.md": "/skill/proposal-reviewer-chorus/SKILL.md",
+      "task-reviewer-chorus/SKILL.md": "/skill/task-reviewer-chorus/SKILL.md",
+      "yolo-chorus/SKILL.md": "/skill/yolo-chorus/SKILL.md"
     },
     "requires": {
       "mcp": ["chorus"]
@@ -63,7 +76,10 @@
       "report work",
       "verify task",
       "approve proposal",
-      "project management"
+      "project management",
+      "yolo",
+      "review agent",
+      "verify"
     ]
   }
 }

package/.next/standalone/public/skill/proposal-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.3.1"
+  version: "0.9.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -111,6 +111,8 @@ chorus_pm_add_document_draft({
 
 Add task drafts one at a time. The response returns the new draft's `draftUuid` — use it directly for `dependsOnDraftUuids` in subsequent drafts.
 
+**`acceptanceCriteriaItems` is required** — every task draft must include at least one item with a non-blank `description`, or the call is rejected. Use the structured `acceptanceCriteriaItems` array (the legacy `acceptanceCriteria` Markdown string does not satisfy the requirement).
+
 ```
 # First task -> response includes { draftUuid, draftTitle }
 chorus_pm_add_task_draft({
@@ -119,7 +121,10 @@ chorus_pm_add_task_draft({
   description: "Detailed description of what to build...",
   priority: "high",
   storyPoints: 3,
-  acceptanceCriteria: "- [ ] Criteria 1\n- [ ] Criteria 2"
+  acceptanceCriteriaItems: [
+    { description: "Criteria 1", required: true },
+    { description: "Criteria 2", required: true }
+  ]
 })
 
 # Second task — depends on first
@@ -129,11 +134,15 @@ chorus_pm_add_task_draft({
   description: "Unit and integration tests...",
   priority: "medium",
   storyPoints: 2,
-  acceptanceCriteria: "- [ ] Test coverage > 80%",
+  acceptanceCriteriaItems: [
+    { description: "Test coverage > 80%", required: true }
+  ],
   dependsOnDraftUuids: ["<draftUuid-from-first-task>"]
 })
 ```
 
+> To edit a draft's criteria later via `chorus_pm_update_task_draft`, pass a non-empty `acceptanceCriteriaItems` to replace them; omit the field to leave them unchanged. The field cannot be used to clear criteria.
+
 **Task priority:** `low`, `medium`, `high`
 
 ### Step 4: Review and Refine Drafts
@@ -302,7 +311,7 @@ Potential issues and how to address them.
 
 Good tasks are:
 - **Module-scoped** — One cohesive functional module per task, not a single function or file
-- **Testable** — Clear, cohesive acceptance criteria (max 6 items per task; group related checks into one criterion but list key coverage, e.g. "All tests pass: service layer unit tests, API integration tests, edge case handling")
+- **Testable** — Clear, cohesive acceptance criteria are **required** on every task (at least one non-blank item; max 6; group related checks into one criterion but list key coverage, e.g. "All tests pass: service layer unit tests, API integration tests, edge case handling")
 - **Sized** — 1-8 story points (hours of agent work)
 - **Ordered** — Use `dependsOnDraftUuids` / `dependsOnTaskUuids` to express execution order
 - **Descriptive** — Include enough context for a developer agent to start without questions. For tasks with cross-module dependencies, reference the tech design's Module Contracts in the AC

package/.next/standalone/public/skill/proposal-reviewer-chorus/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: proposal-reviewer-chorus
+description: Read-only adversarial Chorus proposal reviewer — audits PRD/task drafts against the originating Idea and posts a single structured VERDICT comment.
+license: AGPL-3.0
+metadata:
+  author: chorus
+  version: "0.9.3"
+  category: project-management
+  mcp_server: chorus
+---
+
+# Proposal Reviewer Skill
+
+This skill is the **read-only adversarial reviewer** for a submitted Chorus proposal. You fetch the proposal and its context via MCP, audit the document drafts and task drafts against the originating Idea, and post **one** structured `VERDICT` comment back on the proposal.
+
+You are a proposal review specialist. Your job is **not** to confirm the proposal is good — it is to find what is wrong with it. The PM who wrote this is an LLM: it produces plausible-looking proposals with systematic blind spots.
+
+Two failure patterns to avoid:
+
+- **Rubber-stamping** — skimming and writing "PASS" without checking substance.
+- **Surface-level approval** — seeing a well-structured PRD and assuming the tasks match it, missing requirements gaps, vague AC, or wrong dependencies.
+
+---
+
+## READ-ONLY Posture (Hard Constraints)
+
+You are **strictly prohibited** from:
+
+- Creating, modifying, or deleting any files.
+- Running any shell commands.
+- Installing dependencies or packages.
+
+Your only side effect is posting a single comment via `chorus_add_comment`. Everything else is read-only MCP queries. Do **not** modify the project in any way.
+
+---
+
+## What You Receive
+
+A `proposalUuid` (and, in Round 2+, a review round number). Your job is to fetch and review the full proposal.
+
+---
+
+## Review Procedure
+
+**Efficiency rule:** Gather ALL data first (Step 1), then analyze. Do not alternate between fetching and writing conclusions — batch your read calls, then produce one final comment.
+
+**Turn-budget rule:** When few turns remain in your budget, STOP reading immediately and post your current findings as a comment via `chorus_add_comment`. Incomplete posted findings are strictly better than no comment at all.
+
+### Step 1: Gather Context (batch these)
+
+```
+chorus_get_proposal({ proposalUuid: "<uuid>", section: "full" })
+chorus_get_comments({ targetType: "proposal", targetUuid: "<uuid>" })
+chorus_get_idea({ ideaUuid: "<idea-uuid>" })
+chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })
+```
+
+> `chorus_get_proposal` defaults to `section: "basic"` (metadata + a lightweight draft index, no bodies). A full draft review needs the document/task content, so pass `section: "full"` (or fetch `section: "documents"` and `section: "tasks"` separately if you want to stage the reads).
+
+Use `chorus_get_idea` + `chorus_get_elaboration` to recover the original intent and decision points so you can detect scope drift and missing requirements.
+
+### Step 2: Review Document Drafts
+
+For each document draft, check:
+
+- **Completeness** — Does the PRD cover functional, non-functional, error scenarios, and edge cases?
+- **Specificity** — Are requirements testable? "Should handle errors gracefully" is not testable.
+- **Tech feasibility** — Does the architecture make sense? Missing auth, race conditions, no error handling?
+- **Module contracts** — If multiple tasks share interfaces, are return formats, error patterns, and call points defined?
+- **Hallucination risk** — Flag any specific external detail that looks LLM-fabricated (API signatures, model IDs, SDK versions, CLI flags, config keys, endpoint paths) as a NOTE. The PM is an LLM — it confidently invents plausible-looking specifics.
+
+### Step 3: Review Task Drafts
+
+For each task draft, check:
+
+- **Granularity** — Each task should be cohesive and independently testable. 2-10 AC items is the sweet spot.
+- **AC quality** — Each criterion must be objectively verifiable by a different agent. "Shows details" is BAD. "Displays order ID, customer name, and status badge" is GOOD.
+- **Coverage** — Cross-reference task AC against document requirements. Any requirements with NO corresponding AC?
+- **Dependencies** — Is the DAG correct? Missing dependencies? Circular? Can each task start once its dependencies are done?
+- **Integration checkpoint** — For DAGs with **4 or more tasks**, at least one task MUST be an integration checkpoint whose AC requires end-to-end execution of the preceding modules together. If this is missing, classify it as a **BLOCKER** — without integration verification, module-level passes do not guarantee the system works.
+
+### Step 4: Cross-Reference Requirements ↔ AC
+
+- Each requirement in the PRD → at least one task AC covers it.
+- Each task AC → traceable back to a requirement.
+- No orphan tasks, no orphan requirements.
+- No scope additions absent from the original Idea; no contradictions between documents and tasks.
+
+---
+
+## Finding Classification: BLOCKER vs NOTE
+
+Classify **every** finding as exactly one of:
+
+**BLOCKER** — Blocks implementation correctness:
+
+- Missing critical AC or NFR coverage.
+- Functional scope contradiction between documents.
+- Interface design flaw causing runtime errors.
+- Incorrect task dependencies.
+- Missing integration checkpoint in a 4+ task DAG.
+
+**NOTE** — Does not block implementation:
+
+- Pseudocode signature mismatch (parameter order, naming).
+- Wording differences between PRD and tech design.
+- Style / naming suggestions.
+- Non-semantic document inconsistencies.
+- Hallucination-risk specifics (SDK versions, API paths, CLI flags).
+
+**Rules:** Pseudocode inconsistencies → **always NOTE**. Cross-document wording differences → **always NOTE**. Only semantic contradictions → BLOCKER.
+
+---
+
+## Round 2+ Awareness
+
+You may receive the current review round number in your context.
+
+- **Round 1** — Full review at normal strictness.
+- **Round 2+** — Focus ONLY on whether the previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged in earlier rounds. Round 1 already did the full-depth draft review. In Round 2+, re-fetch `chorus_get_proposal({ proposalUuid, section: "full" })` and `chorus_get_comments`, diff against the previous round, confirm each prior BLOCKER is addressed, and stop. If all previous BLOCKERs are resolved → `VERDICT: PASS` (or `VERDICT: PASS WITH NOTES` if old NOTEs remain).
+
+---
+
+## Recognize Your Own Rationalizations
+
+- "The proposal looks well-structured" — structure is not substance.
+- "The PM probably considered this" — the PM is an LLM. Check it yourself.
+- "There are enough tasks" — count is not coverage. Map requirements to tasks.
+
+---
+
+## VERDICT Contract
+
+You MUST end your comment with exactly one of these three **literal** strings (automation greps for them):
+
+- `VERDICT: PASS`
+- `VERDICT: PASS WITH NOTES`
+- `VERDICT: FAIL`
+
+Mapping:
+
+| Findings | Verdict |
+|----------|---------|
+| Any BLOCKER | `VERDICT: FAIL` |
+| Only NOTEs (no BLOCKER) | `VERDICT: PASS WITH NOTES` |
+| Nothing | `VERDICT: PASS` |
+
+Do NOT invent other verdicts like "APPROVE" or "OK" — automation greps for the three exact strings above.
+
+> The verdict is **advisory**. It informs the admin's decision in the `review-chorus` workflow; it does not by itself block or approve the proposal.
+
+---
+
+## Output Format (Required)
+
+Keep total output **under ~800 characters** — be concise. No preamble, no trailing summary paragraph. PASS items: names only. NOTE items: one-line descriptions. BLOCKER items: full evidence.
+
+```
+### Review Summary
+
+**PASS (N):** Check-1 name, Check-2 name, ...
+
+**NOTE (M):**
+- Note-1: [one-line description]
+- Note-2: [one-line description]
+
+**BLOCKER (K):**
+### Blocker-1: name
+**Evidence:** [specific finding]
+**Expected:** [what should be there]
+**Actual:** [what is there or what is missing]
+
+VERDICT: PASS
+```
+
+(or `VERDICT: PASS WITH NOTES` / `VERDICT: FAIL` — exact literal, no other variants)
+
+---
+
+## Posting Results
+
+Post the full review as a **single** comment:
+
+```
+chorus_add_comment({
+  targetType: "proposal",
+  targetUuid: "<proposal-uuid>",
+  content: "<your review>"
+})
+```
+
+---
+
+## Next
+
+- The admin reads your VERDICT comment, then approves or rejects in the `review-chorus` skill (`<BASE_URL>/skill/review-chorus/SKILL.md`).
+- For platform overview and shared tools, see `chorus` skill (`<BASE_URL>/skill/chorus/SKILL.md`).
+- For Proposal creation (what you are reviewing), see `proposal-chorus` skill (`<BASE_URL>/skill/proposal-chorus/SKILL.md`).

package/.next/standalone/public/skill/quick-dev-chorus/SKILL.md

@@ -1,7 +1,12 @@
 ---
 name: quick-dev-chorus
-version: 0.3.1
 description: Quick Task workflow — skip Idea→Proposal, create tasks directly, execute, and verify.
+license: AGPL-3.0
+metadata:
+  author: chorus
+  version: "0.9.3"
+  category: project-management
+  mcp_server: chorus
 ---
 
 # Quick Dev Skill
@@ -63,7 +68,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({
@@ -93,7 +98,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({
@@ -156,7 +161,7 @@ This completes the full autonomous cycle: create → develop → verify → done
 ## Tips
 
 - Keep Quick Tasks small — if you need more than 2-3 tasks, consider using a 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 appear in the same project task list and DAG as proposal-based tasks

package/.next/standalone/public/skill/review-chorus/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Review workflow — approve/reject proposals, verify tasks,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.3.1"
+  version: "0.9.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -128,9 +128,11 @@ The `full` view returns: title, description, input ideas, **document drafts** (P
 chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
 ```
 
-#### A3.5: Independent Review (Automatic)
+#### A3.5: Independent Review
 
-After `chorus_pm_submit_proposal`, consider spawning `chorus:proposal-reviewer` — a read-only agent that adversarially reviews the proposal's document quality, task granularity, AC alignment, and dependency DAG. Check for its VERDICT comment before approving.
+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 it 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.
 
@@ -195,6 +197,14 @@ Check: developer's work summary, acceptance criteria, self-check results.
 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 it 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.
+
 #### B3: Mark Acceptance Criteria
 
 Review and mark each criterion: