---
name: chorus-yolo
description: Chorus full-auto AI-DLC workflow for OpenCode. Use when driving an end-to-end Idea to Proposal to Execute to Verify lifecycle with reviewer loops and task waves.
license: AGPL-3.0
compatibility: opencode
metadata:
  author: chorus
  version: "0.10.0"
  category: project-management
  mcp_server: lazy-chorus-bridge
  workflow: full-auto
  role: idea:write
  audience: opencode-agents
  source: chorus-plugin
  keywords: full-auto,ai-dlc,proposal-reviewer,task-reviewer,waves,autonomous
  tools: chorus_admin_create_project,chorus_pm_create_idea,chorus_pm_create_proposal,chorus_pm_submit_proposal,chorus_admin_approve_proposal,chorus_submit_for_verify,chorus_admin_verify_task
---


# Yolo Skill

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

## OpenCode Tool Access

In OpenCode plugin mode, Chorus uses the lazy bridge tools `chorus_tools`, `chorus_tool_get`, and `chorus_tool_execute`. Start with `chorus_tools`, inspect one tool with `chorus_tool_get({ toolName: "..." })`, then execute it with `chorus_tool_execute({ toolName: "...", arguments: { ... } })`.

---

## 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 Agent Team parallel task dispatch
4. **Verification** -- task-reviewer adversarial loop + admin verify
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 Agent Team execution
       |  (dev agent + task-reviewer per task)
       v
  Admin Verify each wave --> unblock next
       |
       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

**This workflow requires multiple permission matrix entries on the API key:**

| Permission | Why |
|------------|-----|
| `idea:write` | Idea creation and elaboration |
| `proposal:write` | Proposal creation and draft management |
| `document:write` | PRD and tech design draft management |
| `task:write` | Task claiming, execution, and submission |
| `task:admin` | Proposal approval and task verification |

Sub-agents share the same API key as the main agent. The plugin injects session info into sub-agents, but the granted permissions come from the API key itself, not from hook injection.

**Check at startup:**

```
result = chorus_tool_execute({ toolName: "chorus_checkin", arguments: {} })
permissions = result.agent.permissions ?? {}

hasPermission(resource, action) =
  Array.isArray(permissions)
    ? permissions.includes(`${resource}:${action}`)
    : Array.isArray(permissions[resource])
      ? permissions[resource].includes(action)
      : permissions[`${resource}:${action}`] === true

required = [
  ["idea", "write"],
  ["proposal", "write"],
  ["document", "write"],
  ["task", "write"],
  ["task", "admin"],
]
missing = required.filter(([resource, action]) => !hasPermission(resource, action))

if missing:
  ABORT: "Cannot run chorus-yolo. Missing required permissions: {missing}. Your API key must include idea:write, proposal:write, document:write, task:write, and task:admin."
```

---

## Input

```
chorus-yolo <natural language prompt>
chorus-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

---

## Workflow

### Phase 1: Planning

#### Step 1.1: Resolve Project

Parse the arguments for `--project <uuid>`.

**If `--project` is provided:**
```
chorus_tool_execute({ toolName: "chorus_get_project", arguments: { 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_tool_execute({ toolName: "chorus_search", arguments: { query: "<key terms from prompt>", entityTypes: ["project"] } })

# 2. Or list recent projects to find a match
chorus_tool_execute({ toolName: "chorus_list_projects", arguments: {} })
```

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_tool_execute({ toolName: "chorus_admin_create_project", arguments: {
  name: "<short title derived from prompt>",
  description: "<1-2 sentence summary of the prompt>"
} })
```

#### Step 1.2: Create Idea

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

Then claim it:
```
chorus_tool_execute({ toolName: "chorus_claim_idea", arguments: { ideaUuid: "<idea-uuid>" } })
```

#### Step 1.3: Self-Elaboration

In `chorus-yolo` mode, the agent generates elaboration questions and answers them itself -- no `OpenCode question tool` calls. This preserves an audit trail without interrupting the user.

1. **Generate and submit questions:**
   ```
   chorus_tool_execute({ toolName: "chorus_pm_start_elaboration", arguments: {
     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, scope aspects
     ]
   } })
   ```

2. **Answer immediately** (agent selects best options based on the prompt):
   ```
   chorus_tool_execute({ toolName: "chorus_answer_elaboration", arguments: {
     ideaUuid: "<idea-uuid>",
     answers: [
       { questionId: "q1", selectedOptionId: "a", customText: "Rationale: ..." },
       // ...
     ]
   } })
   ```

   In the normal self-elaboration path there is one active round, so `roundUuid` can be omitted and auto-located.

3. **Validate** (no issues in self-mode):
   ```
   chorus_tool_execute({ toolName: "chorus_pm_validate_elaboration", arguments: {
     ideaUuid: "<idea-uuid>"
   } })
   ```

#### Step 1.4: Create Proposal

1. **Detect authoring mode:**
   - If the project root contains `openspec/` and `openspec --version` works, use OpenSpec mode.
   - Load `chorus-openspec`, pick a kebab-case change slug, and run `openspec new change <slug>` unless the change already exists.
   - If OpenSpec is unavailable, use free-form mode and add the tech design inline through Chorus document drafts.

2. **Create empty container:**
   ```
   chorus_tool_execute({ toolName: "chorus_pm_create_proposal", arguments: {
     projectUuid: "<project-uuid>",
     title: "<feature name>",
     description: "<summary of what the proposal covers>" + (openspecMode ? "\n\nOpenSpec change slug: <slug>" : ""),
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   } })
   ```

3. **OpenSpec mode: author local files and mirror:**
   ```bash
   openspec new change <slug>
   ```

   Author:
   - `proposal.md` in the OpenSpec change directory for `<slug>`
   - `openspec/changes/<slug>/design.md`
   - `openspec/changes/<slug>/specs/**/spec.md`
   - `openspec/changes/<slug>/tasks.md`

   Mirror documents to Chorus by passing local file paths via `contentPath` — do not re-output the file bodies inline:
    ```
    chorus_tool_execute({ toolName: "chorus_pm_add_document_draft", arguments: {
      proposalUuid: "<proposal-uuid>",
      type: "prd",
      title: "PRD: <feature>",
      contentPath: "openspec/changes/<slug>/proposal.md"
    } })
    chorus_tool_execute({ toolName: "chorus_pm_add_document_draft", arguments: {
      proposalUuid: "<proposal-uuid>",
      type: "tech_design",
      title: "Tech Design: <feature>",
      contentPath: "openspec/changes/<slug>/design.md"
    } })
    chorus_tool_execute({ toolName: "chorus_pm_add_document_draft", arguments: {
      proposalUuid: "<proposal-uuid>",
      type: "spec",
      title: "Spec: <capability>",
      contentPath: "openspec/changes/<slug>/specs/<capability>/spec.md"
    } })
    ```

   Convert `tasks.md` into task drafts using `chorus_pm_add_task_draft`, preserving dependencies.

4. **Free-form mode: write the tech design to the Chorus staging directory and add it via `contentPath`:**
   Use OpenCode's native `write` / `edit` tools for the staging file instead of bash-based file writes whenever possible.
   ```
   # Write the tech design content to a file in <chorus-staging-dir> first, then:
   chorus_tool_execute({ toolName: "chorus_pm_add_document_draft", arguments: {
     proposalUuid: "<proposal-uuid>",
     type: "tech_design",
     title: "Tech Design: <feature>",
     contentPath: "<chorus-staging-dir>/design.md"
   } })
   ```

5. **Add task drafts incrementally** (use returned `draftUuid` for dependency chaining):
   ```
   # First task
   result1 = chorus_tool_execute({ toolName: "chorus_pm_add_task_draft", arguments: {
     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_tool_execute({ toolName: "chorus_pm_add_task_draft", arguments: {
     proposalUuid: "<proposal-uuid>",
     title: "<dependent module>",
     description: "...",
     priority: "medium",
     storyPoints: 2,
     acceptanceCriteriaItems: [...],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   } })
   ```

6. **Validate:**
   ```
   chorus_tool_execute({ toolName: "chorus_pm_validate_proposal", arguments: { proposalUuid: "<proposal-uuid>" } })
   ```
   Fix any errors, then proceed.

7. **Submit:**
   ```
   chorus_tool_execute({ toolName: "chorus_pm_submit_proposal", arguments: { proposalUuid: "<proposal-uuid>" } })
   ```
   After this call, the plugin auto-launches `proposal-reviewer` as a child sub-agent and waits for its current VERDICT or timeout before returning the tool result.

---

### Phase 2: Proposal Review Loop

After `chorus_pm_submit_proposal`, the plugin auto-launches `proposal-reviewer` as a read-only child sub-agent and gates the tool result on the current reviewer VERDICT or timeout. When the tool returns:

1. **Read the reviewer's VERDICT:**
   ```
   chorus_tool_execute({ toolName: "chorus_get_comments", arguments: { targetType: "proposal", targetUuid: "<proposal-uuid>" } })
   ```
   Look for the most recent comment containing `VERDICT:`.

2. **Act on the VERDICT:**

   - **PASS** or **PASS WITH NOTES** --
     ```
     chorus_tool_execute({ toolName: "chorus_admin_approve_proposal", arguments: {
       proposalUuid: "<proposal-uuid>",
       reviewNote: "PASS from reviewer. <brief summary of notes if any>"
     } })
     ```
     Tasks and documents materialize automatically. Proceed to Phase 3.

   - **FAIL** --
     Read the BLOCKERs from the reviewer comment. Then:
     ```
     chorus_tool_execute({ toolName: "chorus_pm_reject_proposal", arguments: {
       proposalUuid: "<proposal-uuid>",
       reviewNote: "FAIL from reviewer. Fixing BLOCKERs: <list>"
     } })
     ```
       Revise the drafts (write updated content to staging files first, then upload via `contentPath`):
      ```
      chorus_tool_execute({ toolName: "chorus_pm_update_document_draft", arguments: { proposalUuid: "<proposal-uuid>", draftUuid: "<uuid>", contentPath: "<chorus-staging-dir>/design.md" } })
      chorus_tool_execute({ toolName: "chorus_pm_update_task_draft", arguments: { proposalUuid: "<proposal-uuid>", draftUuid: "<uuid>", ... } })
      ```
      Then resubmit:
      ```
      chorus_tool_execute({ toolName: "chorus_pm_submit_proposal", arguments: { proposalUuid: "<proposal-uuid>" } })
      ```
      After resubmission, the plugin auto-launches and waits for the Round 2 reviewer gate.

3. **Max rounds:** Loop up to `maxProposalReviewRounds` (from plugin config, default 3). If exhausted:
   ```
   STOP: "Proposal review failed after {maxRounds} rounds. Remaining BLOCKERs: <list>. Human review needed. Proposal UUID: <uuid>"
   ```

4. **Reviewer timeout or no current VERDICT?** The plugin reports the reviewer session id in the tool result. Inspect that child session and Chorus comments. If the reviewer exhausted its step budget, resolve manually: either rerun/resubmit for another reviewer gate, treat as PASS WITH NOTES only with explicit judgment, or stop for human review. Do not silently continue on a missing quality-gate verdict.

---

### Phase 3: Task Execution (Wave-Based)

After proposal approval, tasks exist in `open` status. Execute them in dependency-ordered waves using OpenCode subagents. If team creation fails, fall back to main agent execution.

#### Primary: Agent Team (parallel)

```
wave = 1

loop:
  # 1. Find ready tasks
  unblocked = chorus_tool_execute({ toolName: "chorus_get_unblocked_tasks", arguments: { projectUuid: "<project-uuid>" } })

  if no unblocked tasks and all tasks done:
    break  # All complete

  if no unblocked tasks and some tasks not done:
    # Stuck -- tasks failed review and can't proceed
    break with escalation report

  # 2. Start an OpenCode multi-agent workflow for this wave
  coordination_context = "yolo-wave-{wave}"

  # 3. Spawn a sub-agent for each unblocked task
  for each task in unblocked:
    task({
      name: "task-{short-title}",
      prompt: "Your Chorus task UUID: {task.uuid}\nProject UUID: {project-uuid}\n\nImplement the task per its description and acceptance criteria. Read the task, proposal, and project documents for context."
    })

  # 4. Wait for all sub-agents to complete
  #    Each sub-agent follows the chorus-develop workflow:
  #    claim -> in_progress -> develop -> report -> self-check AC -> submit_for_verify
  #    submit_for_verify auto-launches task-reviewer and gates on its current VERDICT or timeout

  # 5. Proceed to Phase 4 (verification) for this wave
  wave += 1
```

**What the sub-agent prompt needs:**
- Task UUID(s)
- Project UUID
- NO session UUID, NO workflow boilerplate -- the plugin auto-injects everything via SubagentStart hook

#### Fallback: Main Agent (sequential)

If OpenCode subagents are not available, permission is denied, or sub-agents crash repeatedly, fall back to executing tasks sequentially as the main agent:

```
for each task in unblocked:
  # Follow the chorus-develop workflow directly as main agent
  chorus_tool_execute({ toolName: "chorus_claim_task", arguments: { taskUuid: "<task-uuid>" } })
  chorus_tool_execute({ toolName: "chorus_update_task", arguments: { taskUuid: "<task-uuid>", status: "in_progress" } })

  # ... implement the task: read context, write code, run tests ...

  chorus_tool_execute({ toolName: "chorus_report_work", arguments: { taskUuid: "<task-uuid>", report: "..." } })
  chorus_tool_execute({ toolName: "chorus_report_criteria_self_check", arguments: { taskUuid: "<task-uuid>", criteria: [...] } })
  chorus_tool_execute({ toolName: "chorus_submit_for_verify", arguments: { taskUuid: "<task-uuid>", summary: "..." } })

  # submit_for_verify auto-launches task-reviewer and gates on its current VERDICT or timeout
  # Proceed to Phase 4 verification for this task before moving to next
```

The fallback is slower (sequential, not parallel) but still completes the pipeline. Reviewer gating works the same way in both modes — the plugin auto-launches and waits for the reviewer after verification submission.

---

### Phase 4: Verification

After each wave's sub-agents complete, verify their tasks:

```
for each task in wave_tasks:
  # 1. Check task status
  task = chorus_tool_execute({ toolName: "chorus_get_task", arguments: { taskUuid: "<task-uuid>" } })

  if task.status != "to_verify":
    # Sub-agent may have failed; skip or handle
    continue

  # 2. Read task-reviewer VERDICT from the gated submit_for_verify result or comments
  comments = chorus_tool_execute({ toolName: "chorus_get_comments", arguments: { targetType: "task", targetUuid: "<task-uuid>" } })
  # Find the most recent comment containing "VERDICT:"

  # 3. Act on VERDICT — three possible outcomes:
  if VERDICT is "PASS":
    # All AC verified, no issues. Mark AC and verify.
    chorus_tool_execute({ toolName: "chorus_mark_acceptance_criteria", arguments: {
      taskUuid: "<task-uuid>",
      criteria: [
        { uuid: "<ac-uuid>", status: "passed", evidence: "<from reviewer>" },
        // ...
      ]
    } })
    chorus_tool_execute({ toolName: "chorus_admin_verify_task", arguments: { taskUuid: "<task-uuid>" } })
    # Task is now "done" -- unblocks dependents

  if VERDICT is "PASS WITH NOTES":
    # All AC verified, minor non-blocking notes. Still mark AC and verify.
    chorus_tool_execute({ toolName: "chorus_mark_acceptance_criteria", arguments: { ... } })
    chorus_tool_execute({ toolName: "chorus_admin_verify_task", arguments: { taskUuid: "<task-uuid>" } })

  if VERDICT is "FAIL":
    # BLOCKERs found. Do NOT verify. Reopen for rework.
    chorus_tool_execute({ toolName: "chorus_admin_reopen_task", arguments: { taskUuid: "<task-uuid>" } })
    # Task returns to "open", will be picked up in next wave
```

After verifying all tasks in the wave, return to Phase 3 to check for newly unblocked tasks.

**Max rounds per task:** Tracked by `maxTaskReviewRounds` from plugin config (default 3). If a task has been reopened `maxRounds` times, skip it and flag for human escalation:

```
ESCALATE: "Task '{title}' failed review after {maxRounds} rounds. Last BLOCKERs: <list>. Manual intervention needed. Task UUID: <uuid>"
```

Continue with remaining tasks -- do not halt the entire pipeline for one stuck task.

**Reviewer timeout or no current VERDICT?** The plugin reports the reviewer session id in the tool result. Inspect that child session and Chorus comments. If the reviewer exhausted its step budget, resolve manually: rerun the verification submission for another reviewer gate, reopen for rework if evidence is unclear, or escalate to a human. Do not silently verify on a missing quality-gate verdict.

---

### Phase 5: Report

After all waves complete, output a markdown summary:

```markdown
## chorus-yolo Complete

**Project:** <project-name> (<project-uuid>)
**Proposal:** <proposal-title> (<proposal-uuid>)
**Idea:** <idea-title> (<idea-uuid>)
**Report:** <report-document-uuid>

### Tasks
| Task | Status | Review Rounds |
|------|--------|---------------|
| <title> | done | 1 |
| <title> | done | 2 |
| <title> | ESCALATED | 3 (max) |

### Summary
- Total tasks: N
- Completed: X / N
- Escalated: Y (need human review)
- Waves executed: W
```

### Phase 5b: Idea Completion Report (mandatory)

A successful `chorus-yolo` run finishes the Idea workflow. After the last proposal/task verification succeeds, call `chorus_create_report` once with the relevant `proposalUuid`. Follow the tool description for the Summary / Decisions / Follow-ups template, and surface the returned `documentUuid` in the final Phase 5 summary.

---

## Error Handling

| Scenario | Action |
|----------|--------|
| Missing permissions at startup | Abort with message listing the required permissions and which are missing |
| Project creation fails | Report error, suggest user create project manually and retry with `--project` |
| Proposal reviewer FAIL after maxRounds | Stop pipeline, report persisting BLOCKERs, suggest manual review |
| Task reviewer FAIL after maxRounds | Flag task as escalation-needed, continue with other tasks |
| Sub-agent crash / no submit | Log error, skip task, pick it up in next wave if possible |
| Ctrl+C | All entities persist in Chorus. User can resume via `chorus-develop` or `chorus-review` |

---

## Tips

- Keep the initial prompt detailed -- the more context you provide, the better the auto-generated proposal quality
- The proposal-reviewer is your quality gate -- if it keeps FAILing, the prompt may be too vague
- Watch the wave count -- if tasks keep getting reopened, consider Ctrl+C and manually reviewing the feedback
- All audit trail is preserved: elaboration Q&A, reviewer VERDICTs, work reports. Check Chorus UI for full history
- For small/simple tasks, consider `chorus-quick-dev` instead -- it skips the Idea->Proposal overhead
- Sub-agents share your API key; ensure it includes `idea:write`, `proposal:write`, `document:write`, `task:write`, and `task:admin` before starting

---

## Next

- To manually review proposals: `chorus-review`
- To manually develop tasks: `chorus-develop`
- To create quick standalone tasks: `chorus-quick-dev`
- For platform overview: `/chorus`