develop-chorus

name	develop-chorus
description	Chorus Development workflow — claim tasks, report work, self-check acceptance criteria, and submit for verification.
license	AGPL-3.0
metadata	{"author":"chorus","version":"0.16.4","category":"project-management","mcp_server":"chorus"}

Develop Skill

This skill covers the Development stage of the AI-DLC workflow: claiming Tasks, doing the work, reporting progress, and submitting for verification.

---

Overview

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

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

---

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

Shared tools (checkin, query, comment, search, notifications): see chorus skill (<BASE_URL>/skill/chorus/SKILL.md)

---

Workflow

Step 1: Check In

chorus_checkin()

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

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>" })
   

Step 5: Start Working

Mark the task as in-progress:

chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })

Dependency enforcement: If this task has unresolved dependencies (dependsOn tasks not in done or closed), the call will be rejected with detailed blocker info. Use chorus_get_unblocked_tasks to find tasks you can start now.

Step 6: Report Progress

Report periodically with chorus_report_work. Consider including:

• What was completed
• Files created or modified
• Git commits and PRs
• Current status / remaining work
• Blockers or questions

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Progress:\n- Created src/services/auth.service.ts\n- Commit: abc1234\n- Remaining: unit tests"
})

Report with status update when complete:

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "All implementation complete:\n- Files: ...\n- PR: https://github.com/org/repo/pull/42\n- All tests passing",
  status: "to_verify"
})

Step 7: Self-Check Acceptance Criteria

Before submitting, check structured acceptance criteria:

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

# If task.acceptanceCriteriaItems is non-empty:
chorus_report_criteria_self_check({
  taskUuid: "<task-uuid>",
  criteria: [
    { uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Unit tests cover this" },
    { uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Verified manually" }
  ]
})

For required criteria, prefer to keep working until you can self-check as passed. Only use failed for optional criteria that are out of scope.

Step 8: Submit for Verification

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Implemented auth feature:\n- Added login/logout endpoints\n- JWT middleware\n- 95% test coverage\n- All AC self-checked (3/3 passed)"
})

to_verify does NOT unblock downstream tasks — only done (after admin verification) does.

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.

Final code-review gateway (after the Idea's LAST task is verified): when the task you just verified is the last task of its idea-rooted proposal, the feature is about to ship — run the ship-time code-review gateway before declaring the Idea done. Spawn a read-only sub-agent that loads the code-reviewer-chorus skill (<BASE_URL>/skill/code-reviewer-chorus/SKILL.md), pass it the ideaUuid + round number, and let it review the Idea's aggregate code change (cross-task integration, architecture, security, regression, feature-level coverage) and post one VERDICT comment on the Idea. PASS / PASS WITH NOTES → ship; FAIL → fix via the quick-dev workflow (<BASE_URL>/skill/quick-dev-chorus/SKILL.md): chorus_create_tasks with proposalUuid set to the current approved proposal so the fix tasks attach to it. Group related small BLOCKERs by default; split only materially large or independently testable fixes. Require AC self-check, independent task review, and admin verification for every fix task. Re-run aggregate review only after every fix is successfully done; a failed or cancelled fix stops the loop and escalates. Do not reopen the already-verified tasks. The plugin's post-verify hook injects this reminder automatically; the verdict is advisory (same canonical pattern). Run it before writing any idea-completion report.

Step 9: Handle Review Feedback

If reopened (verification failed), all acceptance criteria are reset to pending.

1. Check feedback:

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

2. Fix the issues, report fixes, and resubmit.

Step 10: Task Complete

Once Admin verifies (status: done), move to the next available task (back to Step 2).

Step 11: Idea Completion Report (advisory)

If the task you just self-verified was the LAST one of its Idea (every Task across every approved Proposal is now done/closed) and you have document:write, prompt the user and call chorus_create_report on accept. The content parameter's description carries the section template. Skip on decline.

---

Work Report Best Practices

Good report (enables continuity):

Implemented password reset flow:

Files created/modified:
- src/services/auth.service.ts (new)
- src/app/api/auth/reset/route.ts (new)
- tests/auth/reset.test.ts (new)

Git:
- Commit: a1b2c3d "feat: password reset flow"
- PR: https://github.com/org/repo/pull/15

Implementation details:
- POST /api/auth/reset-request: sends email with token
- Token expires after 1 hour, single-use
- Rate limiting: 3 requests/hour/email
- 12 new tests, all passing

Acceptance criteria:
- [x] User can request reset via email
- [x] Reset link expires after 1 hour
- [x] Rate limiting prevents abuse

Bad report: Done.

---

Tips

• Read task comments first — they contain previous work reports for continuity
• Check upstream dependencies — read dependsOn tasks and their comments for interfaces/APIs
• Read the originating proposal — understand design rationale and task DAG
• Use commentCount — skip fetching comments on entities with count 0
• Report progress frequently — include file paths, commits, and PRs
• Write detailed submit summaries — Admin needs them to verify
• If blocked, consider adding a comment and releasing the task
• Prefer finishing one task at a time: complete or release before claiming another

---

When to Release a Task

Release if:

• You cannot complete it (missing knowledge, blocked)
• A higher-priority task needs attention
• You will not finish in a reasonable timeframe

chorus_release_task({ taskUuid: "<task-uuid>" })
chorus_add_comment({ targetType: "task", targetUuid: "<task-uuid>", content: "Releasing: reason..." })

---

Next

• After submitting for verification, an Admin reviews using the review-chorus skill (<BASE_URL>/skill/review-chorus/SKILL.md)
• Human "Start Development" wake: a start_development wake (the human clicked Start Development on the idea-detail panel) means: claim and execute ALL remaining tasks of the idea's approved proposal in dependency order — loop this workflow until no claimable task remains, leaving to_verify and other-session tasks untouched.
• Human "Yolo" wake: a yolo_requested wake (the human clicked Yolo on the idea-detail panel) means: drive the WHOLE idea to done via the yolo skill (the full-auto AI-DLC pipeline), not just the execute stage — read the idea's current state and resume from whatever phase it is in. Unlike start_development it is stage-adaptive, and it must never merge or push a PR without explicit human approval.
• For platform overview and shared tools, see chorus skill (<BASE_URL>/skill/chorus/SKILL.md)