/yolo-chorus

name: yolo-chorus
description: Full-auto AI-DLC pipeline — from prompt to done. Automates the entire Idea -> Proposal -> Execute -> Verify lifecycle.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.24.0"
  category: project-management
  mcp_server: chorus

Yolo Skill

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

> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `mcp__chorus__` prefix on dsh (e.g. `mcp__chorus__chorus_pm_create_proposal`). Bare names are used below for readability — prepend `mcp__chorus__` when invoking. See `chorus` for the full rule.

> **dsh adaptations summarized (details inline below):** (1) elaboration is self-answered with no user interaction; (2) reviewers run inline after each submit by loading the exact reviewer through the `skill` tool in a foreground `subagent` (`run_in_background: false`, so the call waits for the reviewer to finish; the verdict is then read from the Chorus comment), with a read-only self-review fallback; (3) sessions are manual if you dispatch sub-agents; (4) task execution dispatches **one `subagent` per unblocked task** (`run_in_background: true`, whole wave in one message), falling back to **sequential main-agent waves** when `subagent` is unavailable or workers fail repeatedly — there is no team object to create first.

---

Overview

`yolo-chorus` 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** -- dependency-ordered waves: one worker sub-agent per unblocked task, or sequential main-agent execution as fallback 4. **Verification** -- task-reviewer adversarial loop + admin verify 5. **Report** -- completion summary

/yolo <prompt>
       |
       v
  Project + Idea + Elaboration (self-answered) + Proposal
       |
       v
  Proposal Reviewer (inline, up to maxProposalReviewRounds)
       |
       v
  Admin Approve --> Tasks materialize
       |
       v
  Wave execution (loop chorus_get_unblocked_tasks; one subagent per task,
                  or sequential main-agent fallback)
       |  (implement task + task-reviewer per task)
       v
  Admin Verify each task --> unblock next
       |
       v
  Done. Report summary.

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

---

Prerequisites

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

| Needs | Why | |------|-----| | `idea: [write]` | Create ideas, run elaboration | | `proposal: [write, admin]` | Create proposals; approve them | | `task: [write, admin]` | Create, execute, verify tasks | | `project: [write]` | Create the project if none is given |

**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 "/yolo needs {resource}: {missing}. Use an Admin-preset API key."

---

Input

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

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

---

Research routing

During planning, follow the Idea and Proposal routes to `research-chorus` ([shared rules](../research-chorus/SKILL.md)): 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.

Team-managed Ideas (check first)

Call `chorus_get_idea_team_context({ideaUuid})` before executing. If `managed: true` and you are the `orchestrator`, YOLO keeps the Team's division of labor — it only removes the need for a human to approve:

• **Product work**: delegate via `chorus_recommend_team_agent({ideaUuid, role: "product"})` + `chorus_delegate_team_product`, instead of elaborating and writing the proposal yourself (if the recommendation is yourself, do it yourself).
• **Reviews**: follow [Team review routing](../orchestrate-chorus/SKILL.md#team-review-routing) for proposal, task and whole-Idea reviews. Recommend with `role: "review"` and `proposalUuid` / `taskUuid` / neither respectively, rather than always spawning your own reviewer. Self → matching read-only reviewer via the host-specific path in that section in this turn; another agent → one review-request mention, then end the turn. Generic reviewer instructions below do not override Team routing.

**Direct Team review requests:** send them with `chorus_request_review` (target, reviewer, round). The server renders the `Team review request — <kind>, round N` envelope and routes only that reviewer into its review session; a hand-written `chorus_add_comment` envelope never opens a review session. A request must never start a line with `VERDICT:`.

Before reviewing a Team request, you MUST load the current matching proposal/task/code reviewer instructions from the local protocol location, even when reviewing directly in your own session, not only when delegated to a separate review