Quick Dev Skill

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.

Overview

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 explicit task:admin permission → create/claim → implement → self-check AC → submit → independent task review → verify or hand off

Use Quick Dev when:

• Bug fixes with clear reproduction steps
• Small features (< 2 story points)
• Post-delivery patches and gap-filling after a proposal's tasks are done
• Prototype or exploratory tasks
• Urgent hotfixes that can't wait for proposal review

Do NOT use Quick Dev when:

• The feature needs a PRD or tech design document
• Multiple interdependent tasks require upfront planning
• Stakeholder elaboration is needed to clarify requirements
• The work impacts architecture or shared components significantly

For complex work, use the idea and proposal skills instead (skill_view("chorus:idea"), skill_view("chorus:proposal")).

Pre-Flight: Permission Check

Call chorus_checkin and inspect the active agent's effective permissions. Set canVerifyTask to true only when chorus_checkin().agent.permissions.task explicitly contains "admin" (the task:admin permission).

Never infer verification authority from the agent's name, persona, preset/role label, task ownership, or tool availability. Do not ask whether to self-verify: the explicit permission determines the terminal path.

Tools

Workflow

Step 1: Create a Quick Task

acceptanceCriteriaItems is required — chorus_create_tasks rejects any task without at least one non-blank criterion (and rejects the whole batch if any task is missing them). These are also 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:

• Omit for standalone quick tasks (bug fixes, hotfixes, exploratory work)
• Pass to attach the task to an existing proposal — useful for gap-filling, follow-up patches, or continuing work after a proposal's initial tasks are delivered

Step 2: Claim the Task

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

Step 3: Edit Details (if needed)

Use chorus_update_task to refine the task after creation. Tasks always have AC (creation requires them), but update them when your understanding changes during development. Passing acceptanceCriteriaItems replaces the task's criteria with the provided non-empty set; omit the field to leave them unchanged (it cannot be used to clear AC).

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

Step 4: Start Working

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

Workers (delegate_task children with a Team-Lead-created session): pass sessionUuid for attribution:

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

Step 5: Report Progress

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

Step 6: Self-Check Acceptance Criteria

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

Step 7: Submit and Run Independent Review

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Fixed Safari login redirect loop. Changed SameSite cookie policy. All AC passed."
})

Submitting is not final verification. The Chorus Hermes plugin appends a reminder to the chorus_submit_for_verify result; act on it. Build the evidence bundle (diff, commit log, and test output written to files under /tmp/chorus-review/<task-uuid>/ with terminal), then run the required chorus-task-reviewer as a read-only delegate_task child whose context starts with the [chorus-reviewer:task] marker and passes the task UUID, repo path, round cap (3), and evidence paths. The full example is in the review skill (skill_view("chorus:review"), Review Strategy) and in skill_view("chorus:develop") Step 8. delegate_task blocks until the reviewer finishes; then read THIS round's VERDICT: Task comment — the one posted after your dispatch, not an older round's. PASS and PASS WITH NOTES continue. On FAIL, do not verify or hand off: fix every unresolved BLOCKER, repeat AC self-check and submission, then run a fresh independent task review.

Step 8: Permission-Aware Verification

With explicit task:admin, after every required AC self-check passes and independent review has no unresolved BLOCKER, verify and continue autonomously:

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

Without explicit task:admin, do not call the admin tool. Post an evidence-rich comment on the Task with chorus_add_comment containing AC results, test evidence, the latest independent-review verdict, and the exact requested action. @mention the responsible human (prefer chorus_checkin().agent.owner, as @[Name](user:<ownerUuid>)) to perform admin verification, then end the current turn.

This handoff applies in interactive CLI sessions and in Chorus-woken gateway sessions alike. Do not ask in chat instead of commenting, poll for the human response, or rely only on generic notifications. When the human replies or verifies, the chorus gateway platform wakes you in the Idea's session if follow-up is needed.

Session Integration

Quick Tasks work with Hermes delegate_task workers just like proposal-based tasks (see skill_view("chorus:develop"), Parallel Workers):

• Team Lead: create quick tasks, create (or reopen) one Chorus session per worker with chorus_create_session, then run the workers with delegate_task (one child, or a tasks=[...] batch). Each child has an isolated context, so pass the task UUID, project UUID, repo path, session UUID, and the instruction to skill_view("chorus:develop") first in its context.
• Workers: checkin with chorus_session_checkin_task, pass sessionUuid to chorus_update_task and chorus_report_work, checkout with chorus_session_checkout_task, then chorus_submit_for_verify
• Session lifecycle: delegate_task blocks until the workers finish; the Team Lead then calls chorus_close_session for each worker session and runs the task reviewer per task

Tips

• Keep Quick Tasks small — if you need more than 2-3 tasks, consider using the proposal skill (skill_view("chorus:proposal"))
• Acceptance criteria are required at creation time — chorus_create_tasks rejects tasks without them. They are your self-check contract; specific, testable AC enables autonomous verification and makes the entire workflow self-contained
• Use chorus_update_task to refine tasks (including AC) after creation rather than deleting and recreating
• Pass proposalUuid to attach follow-up or gap-filling tasks to an existing proposal — this keeps related work grouped in the same project context and DAG
• Quick Tasks show up in the same project task list and DAG as proposal-based tasks
• Agents with explicit task:admin continue autonomously after AC and independent review pass; all others use the evidence-rich asynchronous human handoff

Next

• For full task lifecycle details, see skill_view("chorus:develop")
• For admin verification, see skill_view("chorus:review")
• For the standard planning flow, see skill_view("chorus:idea") and skill_view("chorus:proposal")
• For platform overview, see skill_view("chorus:chorus")