@chorus-aidlc/chorus-openclaw-plugin 0.3.1 → 0.5.0

package/skills/proposal/SKILL.md

@@ -0,0 +1,397 @@
+---
+name: proposal
+description: Chorus Proposal workflow — create proposals with document and task drafts, manage dependency DAG, validate and submit for review.
+license: AGPL-3.0
+metadata:
+  author: chorus
+  version: "0.9.0"
+  category: project-management
+  mcp_server: chorus
+---
+
+# Proposal Skill
+
+This skill covers the **Planning** stage of the AI-DLC workflow: creating Proposals that contain document drafts (PRD, tech design) and task drafts with dependency DAGs, then submitting them for Admin review.
+
+> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `chorus__` prefix on OpenClaw (e.g. `chorus__chorus_pm_create_proposal`). Bare names are used below for readability — prepend `chorus__` when invoking. See `/chorus` for the full rule.
+
+---
+
+## Overview
+
+After an Idea's elaboration is resolved (see `/idea`), the PM Agent creates a Proposal — a container that holds document drafts and task drafts. On Admin approval, these drafts materialize into real Documents and Tasks.
+
+```
+Elaboration resolved --> Create Proposal --> Add drafts --> Validate --> Submit --> Reviewer --> Admin /review
+```
+
+---
+
+## Tools
+
+**Proposal Management:**
+
+| Tool | Purpose |
+|------|---------|
+| `chorus_pm_create_proposal` | Create empty proposal container |
+| `chorus_pm_validate_proposal` | Validate proposal completeness (returns errors, warnings, info) |
+| `chorus_pm_submit_proposal` | Submit proposal for Admin approval (draft -> pending) |
+
+**Document Drafts:**
+
+| Tool | Purpose |
+|------|---------|
+| `chorus_pm_add_document_draft` | Add document draft to proposal |
+| `chorus_pm_update_document_draft` | Update document draft content |
+| `chorus_pm_remove_document_draft` | Remove document draft from proposal |
+
+**Task Drafts:**
+
+| Tool | Purpose |
+|------|---------|
+| `chorus_pm_add_task_draft` | Add task draft (returns draftUuid for dependency chaining) |
+| `chorus_pm_update_task_draft` | Update task draft |
+| `chorus_pm_remove_task_draft` | Remove task draft from proposal |
+
+**Post-Approval (tasks exist):**
+
+| Tool | Purpose |
+|------|---------|
+| `chorus_create_tasks` | Batch create tasks (supports intra-batch dependencies via draftUuid) |
+| `chorus_pm_assign_task` | Assign a task to a Developer Agent |
+| `chorus_pm_create_document` | Create standalone document |
+| `chorus_pm_update_document` | Update document content (increments version) |
+| `chorus_update_task` (with `addDependsOn` / `removeDependsOn`) | Add or remove task dependencies (with cycle detection) |
+
+**Shared tools** (checkin, query, comment, search, notifications): see `/chorus`
+
+---
+
+## Workflow
+
+### Step 1: Create an Empty Proposal
+
+**Recommended approach:** Create the proposal container first without any drafts, then incrementally add document and task drafts one by one.
+
+```
+chorus_pm_create_proposal({
+  projectUuid: "<project-uuid>",
+  title: "Implement <feature name>",
+  description: "Analysis and implementation plan for Idea #xxx",
+  inputType: "idea",
+  inputUuids: ["<idea-uuid>"]
+})
+```
+
+**Multiple Ideas:** You can combine multiple ideas into one proposal by passing multiple UUIDs in `inputUuids`.
+
+### Step 1.5: Detect OpenSpec mode
+
+Before authoring document drafts, **load the `openspec-aware` skill** and run its **§1 inline detection** (three checks — `CHORUS_OPENSPEC_MODE != "off"`, an `openspec/` directory at the project root, and the `openspec` CLI on `PATH`).
+
+> **OpenClaw note:** there is no Claude Code SessionStart hook to precompute `CHORUS_OPENSPEC_ACTIVE`. You must run the three checks yourself, inline, every time you reach this step. See `openspec-aware` §1.
+
+Branch on the result:
+
+- **OpenSpec active (all three checks pass)** → follow `openspec-aware` §3. Pick `$SLUG`, scaffold `openspec/changes/<slug>/`, author `proposal.md` / `design.md` / `specs/<capability>/spec.md` locally, then create the proposal container (Step 1 above) with the literal line `OpenSpec change slug: <slug>` in `description`, and mirror each local file into a document draft.
+
+  > **⛔ Mandatory in OpenSpec mode:** mirror calls go through the `chorus-api.sh` wrapper with `content` produced by `json_encode_file` — see `openspec-aware` §3.6. Do **not** call `chorus_pm_add_document_draft` directly from the MCP harness with a hand-typed `content` field. Re-typing thousands of lines through the LLM burns 20k+ content tokens per proposal and breaks byte-equality with the local source of truth (`openspec-aware` §2 Rule 1 explains the full reasoning). Skip Step 2 below when in OpenSpec mode — the wrapper-based flow in `openspec-aware` §3.6 replaces it for documents.
+
+- **OpenSpec inactive (any check fails, or `CHORUS_OPENSPEC_MODE=off`)** → proceed with Step 2 unchanged. Author drafts inline as free-form Markdown via direct MCP `chorus_pm_add_document_draft`.
+
+### Step 2: Add Document Drafts
+
+Add document drafts one at a time:
+
+```
+# Add PRD
+chorus_pm_add_document_draft({
+  proposalUuid: "<proposal-uuid>",
+  type: "prd",
+  title: "PRD: <Feature Name>",
+  content: "# PRD: <Feature Name>\n\n## Background\n...\n## Requirements\n..."
+})
+
+# Add Tech Design
+chorus_pm_add_document_draft({
+  proposalUuid: "<proposal-uuid>",
+  type: "tech_design",
+  title: "Tech Design: <Feature Name>",
+  content: "# Technical Design\n\n## Architecture\n...\n## Implementation\n..."
+})
+```
+
+**Document types:** `prd`, `tech_design`, `adr`, `spec`, `guide`
+
+### Step 3: Add Task Drafts
+
+Add task drafts one at a time. The response returns the new draft's `draftUuid` — use it directly for `dependsOnDraftUuids` in subsequent drafts.
+
+```
+# First task -> response includes { draftUuid, draftTitle }
+chorus_pm_add_task_draft({
+  proposalUuid: "<proposal-uuid>",
+  title: "Implement <component>",
+  description: "Detailed description of what to build...",
+  priority: "high",
+  storyPoints: 3,
+  acceptanceCriteria: "- [ ] Criteria 1\n- [ ] Criteria 2"
+})
+
+# Second task — depends on first
+chorus_pm_add_task_draft({
+  proposalUuid: "<proposal-uuid>",
+  title: "Write tests for <component>",
+  description: "Unit and integration tests...",
+  priority: "medium",
+  storyPoints: 2,
+  acceptanceCriteria: "- [ ] Test coverage > 80%",
+  dependsOnDraftUuids: ["<draftUuid-from-first-task>"]
+})
+```
+
+**Task priority:** `low`, `medium`, `high`
+
+### Step 4: Review and Refine Drafts
+
+```
+# Review current state
+chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+
+# Update a document draft
+chorus_pm_update_document_draft({
+  proposalUuid: "<proposal-uuid>",
+  draftUuid: "<draft-uuid>",
+  content: "Updated content..."
+})
+
+# Update a task draft
+chorus_pm_update_task_draft({
+  proposalUuid: "<proposal-uuid>",
+  draftUuid: "<draft-uuid>",
+  description: "Updated description...",
+  dependsOnDraftUuids: ["<other-draft-uuid>"]
+})
+
+# Remove a draft
+chorus_pm_remove_task_draft({
+  proposalUuid: "<proposal-uuid>",
+  draftUuid: "<draft-uuid>"
+})
+```
+
+### Step 5: Validate and Submit
+
+Before submitting, validate to preview issues:
+
+```
+chorus_pm_validate_proposal({ proposalUuid: "<proposal-uuid>" })
+```
+
+Returns `{ valid, issues }` with error, warning, and info levels. Fix errors before submitting.
+
+When validation passes:
+
+```
+chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
+```
+
+This changes the status from `draft` to `pending`. An Admin will review it (see `/review`).
+
+Add a comment explaining your reasoning:
+
+```
+chorus_add_comment({
+  targetType: "proposal",
+  targetUuid: "<proposal-uuid>",
+  content: "This proposal covers... Key decisions: ..."
+})
+```
+
+### Step 5.5: Run the Proposal Reviewer (inline — no hook on OpenClaw)
+
+> **OpenClaw difference:** the Claude Code plugin relies on a PostToolUse hook to inject a "spawn the reviewer" reminder after `chorus_pm_submit_proposal`. **OpenClaw has no such hook.** Run the reviewer step **inline**, right here, immediately after submitting. Do not wait for an injected reminder — it will never come.
+
+Obtain an independent VERDICT before considering the proposal ready for Admin approval:
+
+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** (bundled with this plugin) against the proposal, then wait for it (poll the `subagents` tool or use `sessions_yield` — do NOT detach; you need its VERDICT before proceeding). The sub-agent inherits the plugin skills, so `/proposal-reviewer` is available to it; that skill is read-only and posts a `VERDICT:` comment on the proposal. Example task prompt:
+   > `Run the /proposal-reviewer skill to review proposalUuid <uuid>. Read the proposal, its documents, the idea, and the elaboration; classify findings BLOCKER/NOTE; post your VERDICT comment on the proposal when done.`
+
+2. **Fallback — review it yourself.** If `sessions_spawn` is unavailable on your host (spawning disabled by policy), perform the review yourself as a **focused, read-only pass** following the `/proposal-reviewer` skill's procedure: read `chorus_get_proposal`, `chorus_get_comments`, the linked idea, and the elaboration; check document completeness, task granularity, AC ↔ requirement coverage, the dependency DAG, and integration checkpoints; then record the result yourself via `chorus_add_comment` ending with a `VERDICT:` line (PASS / PASS WITH NOTES / FAIL). Do NOT modify any drafts during this pass — it is review-only. Use the same BLOCKER vs NOTE classification the `/proposal-reviewer` skill defines.
+
+3. **Read the VERDICT and act:**
+   ```
+   chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
+   ```
+   Find the most recent comment containing `VERDICT:`:
+   - **PASS** / **PASS WITH NOTES** — proceed; an Admin can approve (notes are non-blocking).
+   - **FAIL** — go to Step 6 and fix the BLOCKERs before resubmitting.
+
+If you spawned a sub-agent and no new `VERDICT:` comment appears after it returns, it likely exhausted its turn budget. Respawn it ONCE with a concise-budget hint: *"Stay within turn budget. Skip deep verification. Fetch proposal + comments + idea only, skim for obvious BLOCKERs, and post your VERDICT within the first 10 turns."* If still no VERDICT, fall back to reviewing manually (Step 5.5 fallback) and post the VERDICT yourself.
+
+### Step 6: Handle Feedback
+
+After the reviewer runs (or an Admin reviews), if the VERDICT is **FAIL** or the Admin rejects, you need to revise and resubmit.
+
+**IMPORTANT:** A proposal in `pending` status cannot be edited. You **must** reject it first to return it to `draft` status before editing any drafts.
+
+1. **Read feedback:**
+   ```
+   chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
+   chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
+   ```
+   Identify BLOCKERs from the reviewer VERDICT or rejection note.
+
+2. **Reject the proposal** (self-reject your own, or ask admin to reject someone else's):
+   ```
+   chorus_pm_reject_proposal({
+     proposalUuid: "<proposal-uuid>",
+     reviewNote: "Reviewer FAIL. Fixing BLOCKERs: <list>"
+   })
+   ```
+   This returns the proposal to `draft` status. PM agents can only reject their own proposals; admin agents can reject any proposal.
+
+3. **Revise the drafts:**
+   ```
+   chorus_pm_update_document_draft({ proposalUuid: "<proposal-uuid>", draftUuid: "<uuid>", content: "..." })
+   chorus_pm_update_task_draft({ proposalUuid: "<proposal-uuid>", draftUuid: "<uuid>", ... })
+   ```
+
+4. **Resubmit and re-run the reviewer** (Step 5 → Step 5.5 again):
+   ```
+   chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
+   ```
+
+### Step 7: Post-Approval
+
+When the Admin approves:
+- Document drafts become real Documents
+- Task drafts become real Tasks (status: `open`, ready for developers)
+- The Idea's displayed status is automatically derived from Proposal and Task progress -- no manual update needed
+
+### Step 8: Manage Task Dependencies (Optional)
+
+After tasks are created, you can manage dependencies:
+
+**Batch create tasks with intra-batch dependencies:**
+
+```
+chorus_create_tasks({
+  projectUuid: "<project-uuid>",
+  tasks: [
+    { draftUuid: "draft-db", title: "Create database schema", priority: "high", storyPoints: 2 },
+    { draftUuid: "draft-api", title: "Implement API endpoints", priority: "high", storyPoints: 4, dependsOnDraftUuids: ["draft-db"] },
+    { title: "Write integration tests", priority: "medium", storyPoints: 2, dependsOnDraftUuids: ["draft-api"] }
+  ]
+})
+```
+
+**Add/remove dependencies on existing tasks:**
+
+```
+chorus_update_task({ taskUuid: "<task-B-uuid>", addDependsOn: ["<task-A-uuid>"] })
+chorus_update_task({ taskUuid: "<task-B-uuid>", removeDependsOn: ["<task-A-uuid>"] })
+```
+
+Dependencies are validated: same project, no self-dependency, no cycles (DFS detection).
+
+### Step 9: Assign Tasks to Developer Agents (Optional)
+
+```
+chorus_pm_assign_task({ taskUuid: "<task-uuid>", agentUuid: "<developer-agent-uuid>" })
+```
+
+- Task must be `open` or `assigned`
+- Target agent must have `task: ["write"]` permission
+
+---
+
+## Document Writing Guidelines
+
+### PRD Structure
+```markdown
+# PRD: <Feature Name>
+
+## Background
+Why this feature is needed.
+
+## Requirements
+### Functional Requirements
+- FR-1: ...
+
+### Non-Functional Requirements
+- NFR-1: ...
+
+## User Stories
+- As a <role>, I want <action>, so that <benefit>
+
+## Out of Scope
+What is NOT included.
+```
+
+### Tech Design Structure
+```markdown
+# Technical Design: <Feature Name>
+
+## Overview
+High-level approach.
+
+## Architecture
+System design, component interactions.
+
+## Data Model
+Schema changes, new tables.
+
+## API Design
+New/modified endpoints.
+
+## Module Contracts
+Shared conventions across tasks: return value format, error handling pattern, cross-module call points.
+
+## Implementation Plan
+Step-by-step implementation order.
+
+## Risks & Mitigations
+Potential issues and how to address them.
+```
+
+### Task Writing Guidelines
+
+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")
+- **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
+- **Integration checkpoints** — For DAGs with 4+ tasks, include at least one integration checkpoint task at a convergence point whose AC requires end-to-end execution of preceding modules together
+- **Hallucination-aware** — When tasks involve external dependencies, note in the task description that developers should verify specifics (API signatures, CLI flags, config keys, model IDs, etc.) against official docs rather than relying on LLM memory
+
+### Task Granularity
+
+Each task should correspond to an **independently runnable and testable functional module** — not a single function, file, or API endpoint. Avoid splitting closely related functionality into separate tasks; the Chorus workflow overhead per task (claim → implement → self-test → submit → verify) adds up quickly.
+
+**Bad → Good examples:**
+- Bad: `Book Search` + `Book CRUD` (2 tasks) → Good: `Book Management` (1 task covering CRUD + Search for the same entity)
+- Bad: `Chart Rendering` + `Statistics Calculation` (2 tasks) → Good: `Data Analytics` (1 task covering stats + visualization as one module)
+
+---
+
+## Tips
+
+- Keep PRD focused on *what* and *why*; tech design focused on *how*
+- Break large features into cohesive module-scoped tasks — but avoid over-splitting related functionality into too many tiny tasks
+- Add `storyPoints` to help prioritize and estimate effort
+- Keep acceptance criteria cohesive — group related verifications into one item rather than listing each check separately
+- Always set up task dependency DAG — tasks without dependencies are assumed parallelizable
+- When multiple tasks share data formats or call each other, define contracts in the tech design before writing task AC
+- When combining multiple ideas, explain how they relate in the proposal description
+- Always run the reviewer inline after submit (Step 5.5) — OpenClaw has no hook to remind you
+
+---
+
+## Next
+
+- After submission, an Admin will review using `/review`
+- After approval, Developers claim tasks using `/develop`
+- For Idea elaboration, see `/idea`
+- For platform overview, see `/chorus`

package/skills/proposal-reviewer/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: proposal-reviewer
+description: Adversarial read-only review of a submitted Chorus proposal — document completeness, task granularity, AC↔requirement coverage, and the dependency DAG. Invoke after a proposal is submitted; ends with a VERDICT comment.
+license: AGPL-3.0
+metadata:
+  author: chorus
+  version: "0.9.0"
+  category: project-management
+  mcp_server: chorus
+---
+
+# Proposal Reviewer Skill
+
+You have been asked to **review a submitted Chorus proposal**. Your job is **not** to confirm the proposal is good — it's to find what's wrong with it.
+
+> **How you were invoked.** A PM/orchestrator agent spawned you (via the OpenClaw `sessions_spawn` tool) and told you to run this skill against a specific `proposalUuid`. Read it from your task prompt. When you finish, you post one `VERDICT:` comment back to the proposal — 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_proposal`, `chorus__chorus_add_comment`). Bare names are used below for readability — prepend `chorus__` when invoking.
+
+## Hard rules (READ-ONLY)
+
+- **You are READ-ONLY.** Do NOT edit, write, or create files. Do NOT run Bash. Do NOT modify the proposal drafts, the project, or any entity except posting your one review comment.
+- **Keep your comment under 800 characters.** PASS items: names only. NOTE items: one-line description. BLOCKER items: evidence + expected/actual.
+- **Classify every finding** as BLOCKER (blocks implementation) or NOTE (non-blocking). Pseudocode mismatches and cross-doc wording differences are always NOTE.
+- **End with a single line beginning `VERDICT:`** followed by exactly one of `PASS`, `PASS WITH NOTES`, or `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 you are running low on turns/time, STOP reading immediately and post your current findings as a comment via `chorus_add_comment`. Incomplete findings posted are strictly better than no comment at all.
+- **Do NOT rubber-stamp.** Your value is in finding what the PM missed. Batch all data gathering first, then produce one final comment.
+
+You have two failure patterns. **Rubber-stamping**: skimming and writing "PASS" without checking substance. **Surface-level approval**: seeing a well-structured PRD and assuming tasks match, missing requirements gaps, vague AC, or wrong dependencies. The PM who wrote this is an LLM — it produces plausible-looking proposals with systematic blind spots.
+
+## What you receive
+
+A `proposalUuid` (in your task prompt). Fetch and review the full proposal.
+
+## Review procedure
+
+**Efficiency rule:** Gather ALL data in Steps 1–2 before analyzing. Do not alternate between fetching and writing conclusions. Batch your tool calls.
+
+**Step 1: Gather context**
+```
+chorus_get_proposal({ proposalUuid: "<uuid>" })
+chorus_get_comments({ targetType: "proposal", targetUuid: "<uuid>" })
+chorus_get_idea({ ideaUuid: "<idea-uuid>" })
+chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })
+```
+
+**Step 2: Review documents** — 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 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 requirement with NO corresponding AC?
+- **Dependencies**: Is the DAG correct? Can each task start once its dependencies are done?
+- **Integration checkpoints**: For DAGs with 4+ tasks, at least one task must be an integration checkpoint whose AC requires end-to-end execution of preceding modules together. If missing, classify as BLOCKER — module-level passes do not guarantee the system works.
+- **Hallucination risk**: Task descriptions/AC may contain LLM-fabricated specifics. Flag as NOTE — same rule as Step 2.
+
+**Step 4: Cross-check**
+- Do tasks cover ALL requirements from the documents?
+- Are there scope additions not in the original idea?
+- Are there contradictions between documents and tasks?
+
+## Finding classification
+
+**BLOCKER** — blocks implementation correctness: missing critical AC/NFR coverage; functional scope contradiction between documents; interface design flaw causing runtime errors; incorrect task dependencies.
+
+**NOTE** — does not block: pseudocode signature mismatch (parameter order, naming); wording differences between PRD and tech design; style/naming suggestions; non-semantic document inconsistencies.
+
+Rules: Pseudocode inconsistencies → always NOTE. Cross-document wording differences → always NOTE. Only semantic contradictions → 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 areas not flagged before. If all previous BLOCKERs are resolved → VERDICT: PASS (or PASS WITH NOTES if old NOTEs remain). Re-fetch `chorus_get_proposal` + `chorus_get_comments`, diff against the previous round, and stop.
+
+## 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.
+
+## Output format (required)
+
+```
+### Review Summary
+
+**PASS (N):** Check-1 name, Check-2 name, ...
+
+**NOTE (M):**
+- Note-1: [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 / PASS WITH NOTES / FAIL
+```
+
+PASS items: names only. NOTE items: one-line. BLOCKER items: full 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: "proposal",
+  targetUuid: "<proposal-uuid>",
+  content: "<your review>"
+})
+```