Chorus Yolo

Chorus Yolo Skill

Full-auto AI-DLC pipeline. User provides a prompt; agent drives the entire lifecycle: Idea -> Elaboration -> Proposal -> Review -> Execute -> Verify -> Done.

Overview

/chorus-yolo automates the complete AI-DLC workflow. You provide a natural language description of what you want built, and the agent handles everything:

1. Planning -- create project, idea, self-elaboration, proposal with docs & tasks
2. Proposal Review -- proposal-reviewer adversarial loop
3. Execution -- wave-based parallel task dispatch via Kiro subagents
4. Verification -- task-reviewer adversarial loop + admin verify 4.5. Code-Review Gateway -- code-reviewer reviews the Idea's aggregate change before ship (FAIL → add fix tasks → re-run)
5. Report -- completion summary

/chorus-yolo <prompt>
       |
       v
  Project + Idea + Elaboration + Proposal
       |
       v
  Proposal Reviewer (auto, up to maxProposalReviewRounds)
       |
       v
  Admin Approve --> Tasks materialize
       |
       v
  Wave-based subagent execution
       |  (dev subagent + task-reviewer per task)
       v
  Admin Verify each wave --> unblock next
       |
       v
  Code-Review Gateway (auto, up to maxCodeReviewRounds)
       |  PASS --> ship   |   FAIL --> add fix tasks --> re-run
       v
  Done. Report summary.

Escape hatch: Ctrl+C at any time. All created entities (project, idea, proposal, tasks) persist in Chorus. Resume manually via /chorus-develop or /chorus-review.

Prerequisites

The API key needs write + admin on every resource it touches:

Check at startup:

perms = chorus_checkin().agent.permissions
need = { idea: ["write"], proposal: ["write","admin"],
         task: ["write","admin"], project: ["write"] }

for resource, actions in need:
  missing = [a for a in actions if a not in (perms[resource] or [])]
  if missing: ABORT "/chorus-yolo needs {resource}: {missing}. Use an Admin-preset API key."

Input

/chorus-yolo <natural language prompt>
/chorus-yolo <prompt> --project <project-uuid>

• <prompt> -- what you want built (becomes the Idea content). Available as $ARGUMENTS.
• --project <uuid> -- optional; use an existing project instead of creating a new one

Research routing

During planning, follow the Idea and Proposal routes to /chorus-research (shared rules): Idea before formal clarification once focused, Proposal after reusing evidence and only for new gaps or an explicit request. Carry findings and the request context across wakes and brainstorm; do not restart the same investigation on resume. Preserve the existing yolo decision/review gates. A Tracker Research action is research-only even inside a yolo-associated conversation: use the Idea research-only branch, save/report, and return without advancing to elaboration, proposal submission, or development. A yolo request alone does not prove development started; use actual execution facts.

Workflow

Phase 1: Planning

Step 1.1: Resolve Project

Parse the arguments for --project <uuid>.

If --project is provided:

chorus_get_project({ projectUuid: "<uuid>" })

Verify it exists and proceed.

If not provided, search for a suitable existing project first:

# 1. Search for projects matching the prompt topic
chorus_search({ query: "<key terms from prompt>", entityTypes: ["project"] })

# 2. Or list recent projects to find a match
chorus_list_projects()

Review the results. If a project clearly matches the user's intent (same topic, active, relevant scope), use it. If no suitable project exists, create a new one:

chorus_admin_create_project({
  name: "<short title derived from prompt>",
  description: "<1-2 sentence summary of the prompt>"
})

Step 1.2: Create Idea

chorus_pm_create_idea({
  projectUuid: "<project-uuid>",
  title: "<concise title derived from prompt>",
  content: "<full user prompt as-is>"
})

Then claim it:

chorus_claim_idea({ ideaUuid: "<idea-uuid>" })

Step 1.3: Self-Elaboration

In /chorus-yolo mode, the agent generates elaboration questions and answers them itself -- no interactive user questions. This preserves an audit trail without interrupting the user.

Self-elaboration is still a loop. If answering your own questions surfaces a new question, contradiction, or gap, loop back to chorus_pm_start_elaboration for another self-answered round before resolving — don't force a resolve over unresolved ambiguity. There is no human gate in YOLO, so the loop exits on your judgment that nothing material is left open (round cap 10). Steps 1–2 are one round; repeat them as needed, then resolve once in Step 3.

1. Generate and submit questions:

   chorus_pm_start_elaboration({
     ideaUuid: "<idea-uuid>",
     depth: "standard",
     questions: [
       {
         id: "q1",
         text: "<question about scope, architecture, etc.>",
         category: "functional",
         options: [
           { id: "a", label: "<option A>" },
           { id: "b", label: "<option B>" }
         ]
       }
       // ... 5-8 questions covering functional, technical_context, scope aspects
     ]
   })

2. Answer immediately (agent selects best options based on the prompt):

   chorus_answer_elaboration({
     ideaUuid: "<idea-uuid>",
     roundUuid: "<round-uuid>",
     answers: [
       { questionId: "q1", selectedOptionId: "a", customText: "Rationale: ..." },
       // ...
     ]
   })

3. Resolve — in YOLO mode the agent resolves elaboration autonomously, with no human-confirmation gate (the human-confirmation requirement that applies to the interactive /chorus-idea flow is explicitly waived under /chorus-yolo automation):

   chorus_pm_validate_elaboration({
     ideaUuid: "<idea-uuid>"
   })

   chorus_pm_validate_elaboration requires idea:admin. /chorus-yolo already mandates an Admin-preset key in Prerequisites, so this is satisfied. To open another self-elaboration round instead of resolving, just call chorus_pm_start_elaboration again.

Step 1.4: Create Proposal

1. Read the spec mode (already computed). The agentSpawn hook (bin/resolve-spec-mode.sh) has already resolved it — do NOT re-derive. Read the ## Spec Mode section: CHORUS_SPEC_MODE=<lite|openspec|off> + a routing note. Act on it: openspec (usable, shows CHORUS_OPENSPEC_ACTIVE=1) → 2a; off → 2b; lite → 2c. If it says the mode cannot be honored (explicit openspec but unusable), halt and surface it — do NOT fall back or enter 2a with no OpenSpec. (No ## Spec Mode? Source the same resolver; /chorus-openspec-aware §1.) This matters because yolo runs unattended.

2. Create the empty proposal container. The description MUST carry the mode's locator line — OpenSpec: OpenSpec change slug: <slug>; spec-lite: Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/; free-form: none. description is only settable at creation, so decide the slug/dated-path first.

   chorus_pm_create_proposal({
     projectUuid: "<project-uuid>",
     title: "<feature name>",
     description: "<summary>\n\nOpenSpec change slug: <slug>",                          // OpenSpec (2a)
     // description: "<summary>\n\nSpec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/", // spec-lite (2c)
     // description: "<summary>",                                                        // free-form (2b)
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })

   Then branch:

   2a. OpenSpec mode (CHORUS_OPENSPEC_ACTIVE=1). Follow /chorus-openspec-aware §3 end-to-end:

   • Pick $SLUG, run openspec new change "$SLUG" (§3.1–§3.2).
   • Author proposal.md, design.md, and one specs/<capability>/spec.md per capability locally on disk (§3.3). ADDED Requirements only; per-spec fallback to free-form Markdown if MODIFIED/REMOVED is needed.
   • Define the chorus_check_response helper (§6); prefer chorus mcp call … --arg-file content=<file> for mirrors (§3.4/§3.6) — the bash-wrapper fallback's $API + json_encode_file are only needed when chorus is not on PATH.
   • Mirror each local file via chorus mcp call chorus_pm_add_document_draft … --arg-file content=<file> (§3.6; fallback = "$API" mcp-tool chorus_pm_add_document_draft "$PAYLOAD") — one call per file, with the document type from /chorus-openspec-aware §5.

   ⛔ Do not invoke chorus_pm_add_document_draft / chorus_pm_update_document_draft / chorus_pm_update_document from the MCP harness with a hand-typed content field in this branch. Re-typing the markdown body wastes 20k+ tokens per proposal and breaks byte-equality with the local files. See /chorus-openspec-aware §2 Rule 1.

   Then continue to step 3 (task drafts).

   2b. Free-form mode (resolved mode = free-form). Only when step 1 resolved to free-form — i.e. explicit CHORUS_SPEC_MODE=off (unset never comes here: it resolves to OpenSpec when usable, else spec-lite/2c). Add a tech design document draft directly via MCP, content authored inline:

   chorus_pm_add_document_draft({
     proposalUuid: "<proposal-uuid>",
     type: "tech_design",
     title: "Tech Design: <feature>",
     content: "<markdown tech design covering architecture, data model, API, module contracts>"
   })

   2c. spec-lite mode (resolved mode = lite). Load /chorus-spec-lite. Pick $SLUG (a capability). Ensure the durable .chorus/specs/<slug>/spec.md exists (local-only, no ids; use the spec-lite skill's inline durable-spec template) and update it in place. Create this change's dated folder .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/ with its synced Chorus-typed docs (shape = the spec-lite skill's inline dated-folder document template) — prd.md (primary), optional tech_design.md… The description carries the Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/ locator (step 2). Mirror each dated-folder <type>.md to its persistent Document byte-exact — first time chorus mcp call chorus_pm_add_document_draft "{\"proposalUuid\":\"<uuid>\",\"type\":\"prd\",\"title\":\"PRD: <feature>\"}" --arg-file content=.chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/prd.md, later edits via chorus_pm_update_document against the recorded documentUuid (chorus-api.sh fallback when chorus not on PATH). spec.md is never mirrored. No openspec/changes/ scaffold; no tasks.md. Then continue to step 3.

3. Add task drafts incrementally (use returned draftUuid for dependency chaining). acceptanceCriteriaItems is required on every draft — at least one non-blank criterion, or the call is rejected:

   # First task
   result1 = chorus_pm_add_task_draft({
     proposalUuid: "<proposal-uuid>",
     title: "<module name>",
     description: "<what to build, referencing tech design>",
     priority: "high",
     storyPoints: 3,
     acceptanceCriteriaItems: [
       { description: "<testable criterion>", required: true },
       // ...
     ]
   })
   
   # Second task, depends on first
   chorus_pm_add_task_draft({
     proposalUuid: "<proposal-uuid>",
     title: "<dependent module>",
     description: "...",
     priority: "medium",
     storyPoints: 2,
     acceptanceCriteriaItems: [...],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   })

4. Validate:

   chorus_pm_validate_proposal({ proposalUuid: "<proposal-uuid>" })

   Fix any errors, then proceed.

5. Submit:

   chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })

   After this call, the postToolUse hook injects a nudge to spawn the chorus-proposal-reviewer subagent. You MUST spawn it yourself — it is NOT auto-launched — and wait for it to complete before approving.

Reviewer contract (applies to every review gate below)

Every gate in Phases 2, 4 and 4.5 follows the same three steps. They are written once here; the phases below only name their entity and their stage-specific actions.

1. Spawn and wait. Spawn the reviewer as a read-only sub-agent, then wait for it: spawn it with the subagent tool and wait for that call to return. The call's own return value is not the verdict — the verdict is the VERDICT: comment the reviewer posts.
2. Read THIS round's VERDICT. Call chorus_get_comments on the entity and find the VERDICT: comment posted after your dispatch, not an older round's. Do not advance the gate before you have read it.
3. No VERDICT for this round? Check what the reviewer did post:
   • A reported round limit, or any other explicit refusal to review — a deliberate escalation to a human. STOP: do not respawn, do not self-review, do not post a VERDICT of your own.
   • Nothing at all — respawn ONCE, telling it to stay within its turn budget and reserve its last turns for the VERDICT, then apply this same check again to what the retry posts. An explicit refusal from the retry still means STOP; only a second true silence lets you review the entity yourself as a read-only pass and POST the VERDICT, then proceed on what you posted rather than looping forever.

Absence is never a PASS, and a round limit reached by someone else is never yours to clear.