/proposal-chorus

name: proposal-chorus
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.18.1"
  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 `mcp__chorus__` prefix on dsh (e.g. `mcp__chorus__chorus_pm_create_proposal`). Bare names are used below for readability — prepend `mcp__chorus__` when invoking. See `chorus` for the full rule.

---

Overview

After an Idea's elaboration is resolved (see `idea-chorus`), 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.

> **Resolve the spec mode BEFORE you create the container (Step 1.5).** The container `description` must carry the resolved mode's locator line (OpenSpec: `OpenSpec change slug: <slug>`; spec-lite: `Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/`; free-form: none), and `description` is only settable at creation time. So read the `## Spec Mode` block and decide the slug / dated path first, then create the container with the right line already in place.

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`.

> **A theme cannot be a proposal input** — `chorus_pm_create_proposal` rejects any input idea with `isContainer = true`. Derive a child idea from the theme and write the proposal on the child instead. (See the theme-ideas section of the `idea-chorus` skill.)

Step 1.5: Select spec mode

The chorus-dsh bundle resolves **one spec mode** at plugin load and injects a `## Spec Mode` block into your first-step context stating `CHORUS_SPEC_MODE=<lite|openspec|off>` + a routing note (it also publishes `CHORUS_SPEC_MODE` / `CHORUS_OPENSPEC_ACTIVE` to the environment). **Consume that value — do NOT re-derive it.** Resolve the mode here, before creating the container (Step 1), so the `description` carries the right locator line.

> **dsh note:** there is no Claude Code SessionStart hook, but the bundle precomputes the mode the same way. Read the `## Spec Mode` block (or the `CHORUS_SPEC_MODE` / `CHORUS_OPENSPEC_ACTIVE` env vars) — see `openspec-aware-chorus` §1. Only if that context is genuinely absent, resolve the full mode (never hand-roll an OpenSpec-only check that ignores `CHORUS_SPEC_MODE`).

Branch on the resolved mode (three branches):

• **OpenSpec** (`CHORUS_OPENSPEC_ACTIVE=1` line present) → **load the `openspec-aware-chorus` skill** and follow its §3. Pick `$SLUG`, scaffold `openspec/changes/<slug>/`, author `proposal.md` / `design.md` / `specs/<capability>/spec.md` locally, create the container (Step 1) 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 fill `content` from the local file — prefer `chorus mcp call … --arg-file content=<file>`, falling back to the package-local `CHORUS_MCP_CALL` wrapper with `json_encode_file` when `chorus` is not on `PATH` — see `openspec-aware-chorus` §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-chorus` §2 Rule 1). Skip Step 2 below in OpenSpec mode — the file-fill flow in §3.6 replaces it for documents.

• **spec-lite** (`CHORUS_SPEC_MODE=lite`) → **load the `spec-lite-chorus` skill** and follow its flow. Pick `$SLUG` (a **capability**), ensur