/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.24.0"
  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.

---

Session scope for CLI daemon wakes

These rules apply only to wakes handled by an updated Chorus CLI daemon that honors the server-delivered SSE `sessionId`. They do not upgrade OpenClaw, Hermes, or dsh-native session routing; those native runtimes retain their existing behavior. Older daemons may fall back to legacy entity/Idea routing, so do not assume task/review isolation there.

• **Task work:** `task:<uuid>` is a task-scoped session with no Idea-session memory. Fetch the current task, its proposal and documents, and its direct Idea from Chorus before starting work; do not rely on the orchestrator's conversation. Sibling tasks of the same Idea can run concurrently for one agent and may share the working directory. Before editing when siblings share the cwd, work in your own git worktree; the daemon does not create one for you.
• **Review work:** a Team review request sent with `chorus_request_review` uses `review:<type>:<uuid>`, where type is `proposal`, `task`, or `idea` (a code review targets the Idea). It is a read-only review-scoped session with no development-session memory. Fetch the target and current reviewer protocol/context before reviewing; do not implement fixes or perform lifecycle writes. A re-review by the same reviewer of the same target resumes the same review session, preserving review history rather than development memory.
• **Orchestration:** elaboration, proposal work, Start Development, Yolo, and orchestration stay in the bare direct-Idea UUID session (`<directIdeaUuid>`, not `idea:<uuid>`). An orchestrator also assigned a task uses `task:<uuid>` only for task-start/reopen work; its other task wakes (comments, mentions, PASS/FAIL VERDICT replies, Team handoffs) stay in the Idea session. Human instructions, operations, and research requests always use the Idea session, even for a task's developer.

These are backend conversation and wake-queue anchors, not the Chorus Agent Session `sessionUuid` used by session check-in tools. Session separation does not isolate files or change the host's existing session check-in lifecycle.

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: