From chorus
Creates, executes, and verifies small dev tasks directly via Chorus tools, skipping Idea/Proposal. For bug fixes, <2pt features, hotfixes, prototypes.
npx claudepluginhub chorus-aidlc/chorus --plugin chorusThis skill uses the workspace's default tool permissions.
Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) and create tasks directly. Ideal for small, well-understood work. The goal is for agents to **autonomously record their development work and verify task completion** through structured acceptance criteria.
Manages Chorus dev workflow: claim tasks, report progress, self-check criteria, submit for review, and handle sub-agent sessions with Claude Code Agent Teams.
Executes small ad-hoc tasks in Kata projects via quick mode: spawns planner/executors, skips research/verification, tracks in STATE.md quick table. For known quick fixes.
Executes small ad-hoc tasks with GSD guarantees like atomic commits and STATE.md tracking, skipping optional agents. Flags: --discuss, --full, --validate, --research. Subcommands: list, status <slug>, resume <slug>.
Share bugs, ideas, or general feedback.
Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) and create tasks directly. Ideal for small, well-understood work. The goal is for agents to autonomously record their development work and verify task completion through structured acceptance criteria.
The standard AI-DLC flow ensures quality through structured planning, but adds overhead that slows down small tasks. Quick Dev provides a lightweight alternative:
[check admin role] → chorus_create_tasks → chorus_claim_task → in_progress → report → self-check AC → submit for verify → [self-verify if admin] → done
Use Quick Dev when:
Do NOT use Quick Dev when:
For complex work, use /idea + /proposal instead.
Before creating tasks, if you have the admin_agent role, ask the user:
"I have admin privileges. After development, should I verify the task myself, or leave it for another admin to verify?"
This matters because admin agents can call chorus_admin_verify_task to close the loop autonomously. If the user approves self-verification, you can complete the entire create → develop → verify cycle without human intervention. Record the decision and apply it in Step 7.
| Tool | Purpose |
|---|---|
chorus_create_tasks | Create task(s) — omit proposalUuid for standalone Quick Task, or pass it to attach to an existing proposal |
chorus_update_task | Edit task fields (title, description, priority, AC, dependencies) or change status |
chorus_claim_task | Claim a task (open → assigned) |
chorus_report_work | Report progress with optional status update |
chorus_report_criteria_self_check | Self-check acceptance criteria before submitting |
chorus_submit_for_verify | Submit for admin verification |
chorus_admin_verify_task | (admin only) Verify task — use when self-verification is approved |
Always include acceptanceCriteriaItems — these are the foundation for self-checking in Step 6. Write specific, testable criteria that you can objectively verify after development. Vague AC like "works correctly" defeats the purpose; prefer "returns 200 on GET /api/foo with valid token".
chorus_create_tasks({
projectUuid: "<project-uuid>",
tasks: [{
title: "Fix login redirect loop on Safari",
description: "Safari loses session cookie after redirect...",
priority: "high",
storyPoints: 1,
acceptanceCriteriaItems: [
{ description: "Login works on Safari 17+", required: true },
{ description: "Existing Chrome/Firefox behavior unchanged", required: true }
]
}]
})
proposalUuid is optional:
chorus_claim_task({ taskUuid: "<task-uuid>" })
Use chorus_update_task to refine the task after creation. If you skipped AC in Step 1, add them now — you will need them for self-check later. Also update AC when your understanding of the task changes during development.
chorus_update_task({
taskUuid: "<task-uuid>",
description: "Updated with more details...",
acceptanceCriteriaItems: [
{ description: "Login works on Safari 17+", required: true },
{ description: "Added CSRF token handling", required: true }
],
addDependsOn: ["<other-task-uuid>"]
})
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })
Sub-agents: pass sessionUuid for attribution:
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress", sessionUuid: "<session-uuid>" })
chorus_report_work({
taskUuid: "<task-uuid>",
report: "Fixed Safari cookie issue:\n- Root cause: SameSite=Strict incompatible with redirect\n- Changed to SameSite=Lax\n- Commit: abc1234",
sessionUuid: "<session-uuid>"
})
chorus_report_criteria_self_check({
taskUuid: "<task-uuid>",
criteria: [
{ uuid: "<ac-uuid-1>", devStatus: "passed", devEvidence: "Tested on Safari 17.2" },
{ uuid: "<ac-uuid-2>", devStatus: "passed", devEvidence: "Chrome/Firefox regression tests pass" }
]
})
chorus_submit_for_verify({
taskUuid: "<task-uuid>",
summary: "Fixed Safari login redirect loop. Changed SameSite cookie policy. All AC passed."
})
Admin self-verification: If you have the admin_agent role and the user approved self-verification in the Pre-Flight check, you can verify the task yourself immediately after submitting:
chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
This completes the full autonomous cycle: create → develop → verify → done.
Quick Tasks work with Claude Code Agent Teams just like proposal-based tasks:
sessionUuid to chorus_update_task and chorus_report_work/proposalchorus_update_task to refine tasks (including AC) after creation rather than deleting and recreatingproposalUuid to attach follow-up or gap-filling tasks to an existing proposal — this keeps related work grouped in the same project context and DAG/develop/review/idea and /proposal/chorus