/develop-chorus

name: develop-chorus
description: Chorus Development workflow — claim tasks, report work, manage sessions, and run wave-based execution on dsh.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.18.1"
  category: project-management
  mcp_server: chorus

Develop Skill

This skill covers the **Development** stage of the AI-DLC workflow: claiming Tasks, writing code, reporting progress, submitting for verification, and managing sessions for sub-agent observability.

> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `mcp__chorus__` prefix on dsh (e.g. `mcp__chorus__chorus_claim_task`). Bare names are used below for readability — prepend `mcp__chorus__` when invoking. See `chorus` for the full rule.

---

Overview

Developer Agents take Tasks created by PM Agents (via `proposal-chorus`) and turn them into working code. Each task follows:

claim --> in_progress --> report work --> self-check AC --> submit for verify --> reviewer --> Admin /review

For multi-task execution, dispatch **one `subagent` per unblocked task** (whole wave in one message), falling back to **sequential waves** (the main agent works tasks in dependency order) when `subagent` is unavailable or workers fail repeatedly — see [Wave-Based Execution](#wave-based-execution-on-dsh) below.

---

Tools

**Task Lifecycle:**

| Tool | Purpose | |------|---------| | `chorus_claim_task` | Claim an open task (open -> assigned) | | `chorus_release_task` | Release a claimed task (assigned -> open) | | `chorus_update_task` | Update task status (in_progress / to_verify) | | `chorus_submit_for_verify` | Submit task for admin verification with summary |

**Work Reporting:**

| Tool | Purpose | |------|---------| | `chorus_report_work` | Report progress or completion (writes comment + records activity, with optional status update) |

**Acceptance Criteria:**

| Tool | Purpose | |------|---------| | `chorus_report_criteria_self_check` | Report self-check results (passed/failed + optional evidence) on structured acceptance criteria |

**Session (sub-agents only — main agent skips these):**

| Tool | Purpose | |------|---------| | `chorus_create_session` | Create a session for a sub-agent (manual on dsh — see below) | | `chorus_session_checkin_task` | Checkin to a task before starting work | | `chorus_session_checkout_task` | Checkout from a task when work is done | | `chorus_close_session` | Close the session when the sub-agent finishes |

Sub-agents: always pass `sessionUuid` to `chorus_update_task` and `chorus_report_work` for attribution. Main agent / Team Lead: call these tools without `sessionUuid` — no session needed.

**Shared tools** (checkin, query, comment, search, notifications): see `chorus`

---

Workflow

Step 1: Check In

chorus_checkin()

Review your persona, current assignments, and pending work counts.

Step 1.5: Manage Your Session (Sub-Agents Only)

**Skip if you are the main agent.**

> **dsh difference:** the Claude Code plugin auto-creates and auto-injects a sub-agent's session via a SubagentStart hook. **dsh does not run that hook.** Session handling is **manual**: if you are a sub-agent and the host did not hand you a `sessionUuid`, create one yourself once at the start, keep it for all task operations, and close it when you finish.

# Create your own session (only if no sessionUuid was provided to you)
chorus_create_session({ name: "<descriptive-worker-name>" })
# -> keep the returned sessionUuid for every task call below

If the dsh host *did* inject a `sessionUuid` into your prompt (some hosts forward parent context), reuse it instead of creating a new one. When in doubt, create one — duplicate idle sessions are harmless and auto-go-inactive after 1h.

Step 2: Find Work

chorus_get_available_tasks({ projectUuid: "<project-uuid>" })

Or check existing assignments:

chorus_get_my_assignments()

Step 3: Claim a Task

chorus_get_task({ taskUuid: "<task-uuid>" })  # Review first
chorus_claim_task({ taskUuid: "<task-uuid>" })

Check: description, acceptance criteria, priority, story points, related proposal/documents.

Step 4: Gather Context

Each task and proposal includes a `commentCount` field — use it to decide which entities have discussions worth reading.

1. **Read the task** and identify dependencies:

   chorus_get_task({ taskUuid: "<task-uuid>" })

Pay attention to `dependsOn` (upstream tasks) and `commentCount`.

2. **Read task comments** (contains previous work reports, progress, feedback):

   chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })

3. **Review upstream dependency tasks** — your work likely builds on theirs:

   chorus_get_task({ taskUuid: "<dependency-task-uuid>" })
   chorus_get_comments({ targetType: "task", targetUuid: "<dependency-task-uuid>" })

Look for: files created, API contracts, interfaces, trade-offs.

4. **Read the originating proposal** for design intent:

   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):

   chorus_get_documents({ projectUuid: "<project-uuid>" })

> **Document update flow (OpenSpec mode):** if the originating proposal `description` contains a line `OpenSpec change slug: <slug>`, the project's PRD / tech_design / spec Documents are **mirrors** of files under `openspec/changes/<slug>/`. To update such a Document (e.g. clarify an AC, fix a spec scenario before resubmitting), load the `openspec-aware-chorus` skill and follow §3.8: edit the local `.md` file first, then mirror it — prefer `chorus mcp call … --arg-file content=<file>`, falling back to the package-local `CHORUS_MCP_CALL` wrapp