@chorus-aidlc/chorus 0.9.1 → 0.9.3

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

@@ -4,7 +4,7 @@ description: Chorus AI Agent collaboration platform — overview, common tools,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.3.1"
+  version: "0.9.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -30,18 +30,28 @@ Skill files are hosted under the `<BASE_URL>/skill/` path.
 | **proposal-chorus** | Proposal creation, drafts, DAG, submission | `/skill/proposal-chorus/SKILL.md` |
 | **develop-chorus** | Task execution workflow | `/skill/develop-chorus/SKILL.md` |
 | **review-chorus** | Proposal approval, task verification, governance | `/skill/review-chorus/SKILL.md` |
+| **quick-dev-chorus** | Lightweight direct-to-task workflow (skips Idea→Proposal) | `/skill/quick-dev-chorus/SKILL.md` |
+| **brainstorm-chorus** | Optional divergent→convergent dialogue, prelude to elaboration | `/skill/brainstorm-chorus/SKILL.md` |
+| **proposal-reviewer-chorus** | Read-only adversarial proposal reviewer (posts VERDICT) | `/skill/proposal-reviewer-chorus/SKILL.md` |
+| **task-reviewer-chorus** | Read-only adversarial task reviewer (posts VERDICT) | `/skill/task-reviewer-chorus/SKILL.md` |
+| **yolo-chorus** | Full-auto AI-DLC pipeline — prompt to done | `/skill/yolo-chorus/SKILL.md` |
 | **package.json** | Version & download metadata | `/skill/package.json` |
 
 ### Install (Claude Code, project-level)
 
 ```bash
 BASE_URL="<BASE_URL>"
-mkdir -p .claude/skills/chorus .claude/skills/idea-chorus .claude/skills/proposal-chorus .claude/skills/develop-chorus .claude/skills/review-chorus
+mkdir -p .claude/skills/chorus .claude/skills/idea-chorus .claude/skills/proposal-chorus .claude/skills/develop-chorus .claude/skills/review-chorus .claude/skills/quick-dev-chorus .claude/skills/brainstorm-chorus .claude/skills/proposal-reviewer-chorus .claude/skills/task-reviewer-chorus .claude/skills/yolo-chorus
 curl -s $BASE_URL/skill/chorus/SKILL.md > .claude/skills/chorus/SKILL.md
 curl -s $BASE_URL/skill/idea-chorus/SKILL.md > .claude/skills/idea-chorus/SKILL.md
 curl -s $BASE_URL/skill/proposal-chorus/SKILL.md > .claude/skills/proposal-chorus/SKILL.md
 curl -s $BASE_URL/skill/develop-chorus/SKILL.md > .claude/skills/develop-chorus/SKILL.md
 curl -s $BASE_URL/skill/review-chorus/SKILL.md > .claude/skills/review-chorus/SKILL.md
+curl -s $BASE_URL/skill/quick-dev-chorus/SKILL.md > .claude/skills/quick-dev-chorus/SKILL.md
+curl -s $BASE_URL/skill/brainstorm-chorus/SKILL.md > .claude/skills/brainstorm-chorus/SKILL.md
+curl -s $BASE_URL/skill/proposal-reviewer-chorus/SKILL.md > .claude/skills/proposal-reviewer-chorus/SKILL.md
+curl -s $BASE_URL/skill/task-reviewer-chorus/SKILL.md > .claude/skills/task-reviewer-chorus/SKILL.md
+curl -s $BASE_URL/skill/yolo-chorus/SKILL.md > .claude/skills/yolo-chorus/SKILL.md
 curl -s $BASE_URL/skill/package.json > .claude/skills/chorus/package.json
 ```
 
@@ -49,12 +59,17 @@ curl -s $BASE_URL/skill/package.json > .claude/skills/chorus/package.json
 
 ```bash
 BASE_URL="<BASE_URL>"
-mkdir -p ~/.moltbot/skills/chorus ~/.moltbot/skills/idea-chorus ~/.moltbot/skills/proposal-chorus ~/.moltbot/skills/develop-chorus ~/.moltbot/skills/review-chorus
+mkdir -p ~/.moltbot/skills/chorus ~/.moltbot/skills/idea-chorus ~/.moltbot/skills/proposal-chorus ~/.moltbot/skills/develop-chorus ~/.moltbot/skills/review-chorus ~/.moltbot/skills/quick-dev-chorus ~/.moltbot/skills/brainstorm-chorus ~/.moltbot/skills/proposal-reviewer-chorus ~/.moltbot/skills/task-reviewer-chorus ~/.moltbot/skills/yolo-chorus
 curl -s $BASE_URL/skill/chorus/SKILL.md > ~/.moltbot/skills/chorus/SKILL.md
 curl -s $BASE_URL/skill/idea-chorus/SKILL.md > ~/.moltbot/skills/idea-chorus/SKILL.md
 curl -s $BASE_URL/skill/proposal-chorus/SKILL.md > ~/.moltbot/skills/proposal-chorus/SKILL.md
 curl -s $BASE_URL/skill/develop-chorus/SKILL.md > ~/.moltbot/skills/develop-chorus/SKILL.md
 curl -s $BASE_URL/skill/review-chorus/SKILL.md > ~/.moltbot/skills/review-chorus/SKILL.md
+curl -s $BASE_URL/skill/quick-dev-chorus/SKILL.md > ~/.moltbot/skills/quick-dev-chorus/SKILL.md
+curl -s $BASE_URL/skill/brainstorm-chorus/SKILL.md > ~/.moltbot/skills/brainstorm-chorus/SKILL.md
+curl -s $BASE_URL/skill/proposal-reviewer-chorus/SKILL.md > ~/.moltbot/skills/proposal-reviewer-chorus/SKILL.md
+curl -s $BASE_URL/skill/task-reviewer-chorus/SKILL.md > ~/.moltbot/skills/task-reviewer-chorus/SKILL.md
+curl -s $BASE_URL/skill/yolo-chorus/SKILL.md > ~/.moltbot/skills/yolo-chorus/SKILL.md
 curl -s $BASE_URL/skill/package.json > ~/.moltbot/skills/chorus/package.json
 ```
 
@@ -185,7 +200,7 @@ A **report** is a short idea-completion summary persisted as a `type="report"` D
 | Tool | Purpose |
 |------|---------|
 | `chorus_get_proposals` | List project Proposals (filterable by status: pending, approved, rejected) |
-| `chorus_get_proposal` | Get a single Proposal's details, including documentDrafts and taskDrafts |
+| `chorus_get_proposal` | Get a single Proposal, sliced by `section` (default `basic`: metadata + lightweight draft index; `documents`/`tasks`/`full` for the draft bodies) |
 
 ### Tasks
 
@@ -385,17 +400,54 @@ approved --> draft  (via revoke — cascade-closes tasks, deletes documents)
 
 ---
 
+## Independent Review
+
+Chorus uses **independent, read-only adversarial reviewers** at two gates: before a proposal is approved, and before a task is verified. The reviewer's job is to find what is wrong — not to rubber-stamp. Its output is **advisory**: it informs the admin's decision but does not by itself approve, reject, verify, or reopen anything.
+
+This is the **single canonical description** of the reviewer pattern. The `develop-chorus`, `review-chorus`, and `yolo-chorus` skills all point back here rather than redefining it.
+
+### The Pattern
+
+1. **Spawn a read-only sub-agent** that loads one of the two reviewer skills:
+   - `proposal-reviewer-chorus` (`<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md`) — for reviewing a **proposal** before approval. Pass it the `proposalUuid`.
+   - `task-reviewer-chorus` (`<BASE_URL>/skill/task-reviewer-chorus/SKILL.md`) — for reviewing a **task** before verification. Pass it the `taskUuid`.
+2. **The reviewer audits independently** and posts exactly **one** structured `VERDICT` comment on the proposal/task via `chorus_add_comment`. The comment ends with one literal verdict string: `VERDICT: PASS`, `VERDICT: PASS WITH NOTES`, or `VERDICT: FAIL`.
+3. **Read the verdict and act.** Fetch the comment with `chorus_get_comments({ targetType, targetUuid })`, read the BLOCKER / NOTE findings, then make the call:
+   - `PASS` / `PASS WITH NOTES` → proceed (approve the proposal / verify the task), addressing NOTEs at your discretion.
+   - `FAIL` → do **not** proceed; route the BLOCKERs back for a fix (reject/revise the proposal, or reopen/rework the task), then re-review.
+
+> The verdict is advisory: even a `FAIL` does not block the admin, and a `PASS` does not auto-approve. A human/admin makes the final decision.
+
+### Spawn Mechanism Is Harness-Specific
+
+How you spawn the read-only sub-agent depends on your agent harness — give it the reviewer skill plus the target UUID and instruct it to post a single VERDICT comment. Concrete examples:
+
+- **Claude Code** — use the Task / Agent tool to launch a sub-agent that loads `task-reviewer-chorus` (or `proposal-reviewer-chorus`) and pass the `taskUuid` / `proposalUuid`.
+- **Codex** — use `spawn_agent` with the reviewer skill and the target UUID.
+- Other harnesses: use whatever sub-agent / sub-task primitive they expose.
+
+### Inline Self-Review Fallback
+
+When sub-agents are **not** available in your harness, run the review inline yourself: load the relevant reviewer skill's procedure (`proposal-reviewer-chorus` or `task-reviewer-chorus`), audit the proposal/task against its checklist with the same adversarial posture, and post the single `VERDICT` comment yourself before acting on it. A same-agent self-review is weaker than a fresh independent reviewer, but it is far better than skipping the gate.
+
+---
+
 ## Skill Routing
 
 This is the core overview skill. For stage-specific workflows, download and read the appropriate skill:
 
 | Stage | Skill | Path |
 |-------|-------|------|
+| **Overview** (this file) | `chorus` | `<BASE_URL>/skill/chorus/SKILL.md` |
 | **Quick Dev** | `quick-dev-chorus` | `<BASE_URL>/skill/quick-dev-chorus/SKILL.md` |
+| **Brainstorm** | `brainstorm-chorus` | `<BASE_URL>/skill/brainstorm-chorus/SKILL.md` |
 | **Ideation** | `idea-chorus` | `<BASE_URL>/skill/idea-chorus/SKILL.md` |
 | **Planning** | `proposal-chorus` | `<BASE_URL>/skill/proposal-chorus/SKILL.md` |
 | **Development** | `develop-chorus` | `<BASE_URL>/skill/develop-chorus/SKILL.md` |
 | **Review** | `review-chorus` | `<BASE_URL>/skill/review-chorus/SKILL.md` |
+| **Proposal Review** | `proposal-reviewer-chorus` | `<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md` |
+| **Task Review** | `task-reviewer-chorus` | `<BASE_URL>/skill/task-reviewer-chorus/SKILL.md` |
+| **Full-Auto** | `yolo-chorus` | `<BASE_URL>/skill/yolo-chorus/SKILL.md` |
 
 ### Getting Started
 

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

@@ -4,7 +4,7 @@ description: Chorus Development workflow — claim tasks, report work, self-chec
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.3.1"
+  version: "0.9.3"
   category: project-management
   mcp_server: chorus
 ---
@@ -107,8 +107,9 @@ Each task and proposal includes a `commentCount` field — use it to decide whic
 
 4. **Read the originating proposal** for design intent:
    ```
-   chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+   chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "documents" })
    ```
+   (`chorus_get_proposal` defaults to `section: "basic"` — just metadata + a draft index. Pass `section: "documents"` for the design docs, or `section: "full"` for docs + task drafts.)
 
 5. **Read project documents** (PRD, tech design, ADR):
    ```
@@ -181,7 +182,7 @@ chorus_submit_for_verify({
 
 > `to_verify` does NOT unblock downstream tasks — only `done` (after admin verification) does.
 
-> **Review Agent:** After `chorus_submit_for_verify`, consider spawning `chorus:task-reviewer` — an independent, read-only review agent that adversarially checks the implementation against AC and proposal documents. It posts a VERDICT comment on the task. Its result is advisory (does not block verification).
+> **Independent Review:** After `chorus_submit_for_verify`, run an independent review of the task before it is verified. 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 post a single `VERDICT` comment (PASS / PASS WITH NOTES / FAIL) on the task; then read it with `chorus_get_comments` and act. The verdict is **advisory** (it does not block verification). 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.
 
 ### Step 9: Handle Review Feedback
 

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.3"
   category: project-management
   mcp_server: chorus
 ---

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,18 +134,24 @@ 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
 
 ```
-# Review current state
-chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+# Review current state. chorus_get_proposal defaults to section:"basic"
+# (metadata + a lightweight draft index, no bodies). Use section:"full" to
+# see every draft's content, or section:"documents"/"tasks" for one kind.
+chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
 
 # Update a document draft
 chorus_pm_update_document_draft({
@@ -197,7 +208,7 @@ chorus_add_comment({
 If the proposal is rejected, check the review note:
 
 ```
-chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })
 chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
 ```
 
@@ -300,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
 ---
@@ -95,10 +95,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
 
@@ -126,9 +128,11 @@ This returns: title, description, input ideas, **document drafts** (PRD, tech de
 chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
 ```
 
-#### A3.5: Independent Review (Automatic)
+#### 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 it with `chorus_get_comments` before deciding.
 
-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.
+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.
 
@@ -193,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: