Yolo Chorus

Yolo Skill

Full-auto AI-DLC pipeline. The user provides one prompt; you drive the entire lifecycle: Idea -> Elaboration -> Proposal -> Review -> Execute -> Verify -> Done. No interactive prompts, no human in the loop unless the pipeline gets stuck.

This skill is framework-neutral: it never assumes a specific agent harness. Every reviewer and worker is described as "spawn a sub-agent" with a concrete example or two, and every step has an inline single-agent fallback so the pipeline still completes when sub-agents are unavailable.

Overview

You take a natural-language description of what to build, and you handle everything:

1. Planning — resolve/create a project, create an Idea, self-elaborate, draft a Proposal (tech-design doc + task DAG), validate, submit.
2. Proposal Review — adversarial review loop against the proposal-reviewer-chorus skill.
3. Execution — dependency-ordered, wave-based task dispatch.
4. Verification — adversarial review loop against the task-reviewer-chorus skill + admin verify. 4.5. Code-Review Gateway — adversarial review loop against the code-reviewer-chorus skill over the Idea's aggregate change, before ship (FAIL → add fix tasks → re-run).
5. Report — completion summary + a mandatory Idea Completion Report.

<prompt>
   |
   v
Project + Idea + Self-Elaboration + Proposal
   |
   v
Proposal Review loop  (up to maxProposalReviewRounds, default 3)
   |   PASS / PASS WITH NOTES -> approve ;  FAIL -> reject + revise + resubmit
   v
Admin Approve  -->  Documents + Tasks materialize (tasks land in `open`)
   |
   v
Wave-based Execution  --  chorus_get_unblocked_tasks
   |   dispatch one worker sub-agent per unblocked task (fallback: sequential main agent)
   v
Verification loop  (up to maxTaskReviewRounds, default 3)
   |   PASS / PASS WITH NOTES -> mark AC + verify ;  FAIL -> reopen
   |   verify unblocks dependents -> loop back to Execution
   v
Code-Review Gateway  (all tasks done; up to maxCodeReviewRounds, default 3)
   |   PASS / PASS WITH NOTES -> ship ;  FAIL -> add fix tasks -> Execution -> re-run
   v
Done  -->  Report summary + mandatory Idea Completion Report

First-principles alignment (a stage-tailored instruction in every reviewer). The proposal-, task-, and code-reviewer each also verify, top-down, that the work still serves the original Idea's intent — building the intent baseline from the directly-attached Idea it resolves from the entity under review — via the existing chorus_get_idea + chorus_get_elaboration + chorus_get_comments, counting human-authored content only — and flagging scope creep, requirement loss / shrink, or semantic drift. Unauthorized drift is a BLOCKER → FAIL / reject, downgraded to a cited NOTE only when traceable to a human-originated authorization (a human-authored Idea comment, a human-answered elaboration entry, or an explicit human override) — an agent's own comment never authorizes. In /yolo there is no human at the gate, so a self-generated (agent-authored) elaboration or comment does NOT clear alignment drift: fix the drift (reject/reopen + revise) rather than rationalizing it away.

Escape hatch: Interrupt at any time. Every created entity (project, idea, proposal, tasks, comments) persists in Chorus. Resume manually via develop-chorus or review-chorus.

Base URL: Skill files are hosted under <BASE_URL>/skill/. The user provides the Chorus access URL (e.g. https://chorus.acme.com or http://localhost:8637), referred to as <BASE_URL> below. See chorus skill (<BASE_URL>/skill/chorus/SKILL.md) for platform overview and shared tools.

Prerequisites

Yolo touches every resource and acts as PM, developer, AND admin. The API key MUST carry write + admin on the resources it drives:

Permission preflight — run this before doing anything else:

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

missing = []
for resource, actions in need:
  for a in actions:
    if a not in (perms[resource] or []):
      missing.append(f"{resource}:{a}")

if missing:
  ABORT "yolo requires the following permissions, which this API key lacks: "
        + ", ".join(missing)
        + ". Use an Admin-preset API key (all 15 permissions) and retry."

List every missing resource:action pair in the abort message — do not stop at the first one — so the user can fix the key in one pass. Do not silently degrade or skip phases when a permission is missing; abort cleanly.

Input

<natural language prompt of what to build>
<prompt>   (with an optional existing-project hint, e.g. a project UUID or name)

• prompt — what you want built. Becomes the Idea content verbatim.
• existing-project hint (optional) — a project UUID or name to reuse instead of creating a new project. If absent, you search for a match and create one only when none fits.

Keep the prompt detailed: the richer the input, the better the auto-generated proposal, and the fewer review rounds it takes.

Workflow

Phase 1: Planning

Step 1.1: Resolve Project

If the user supplied a project UUID:

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

Confirm it exists and reuse it.

Otherwise, search for a suitable existing project first:

# Search by topic
chorus_search({ query: "<key terms from prompt>", entityTypes: ["project"] })
# Or list recent projects
chorus_list_projects()

If a project clearly matches the user's intent (same topic, active, relevant scope), reuse it. Only when no project fits, create one:

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

Step 1.2: Create the Idea

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

Then claim it so you own the elaboration:

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

Step 1.3: Self-Elaboration (no interactive prompts)

In yolo mode you generate the elaboration questions AND answer them yourself — there are NO interactive user prompts. This preserves a decision audit trail without interrupting anyone.

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 mode, 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, data model, etc.>",
         category: "functional",
         options: [
           { id: "a", label: "<option A>" },
           { id: "b", label: "<option B>" }
         ]
       }
       // ... 5-8 questions covering functional, technical_context, and scope aspects
     ]
   })
   

2. Answer immediately — pick the option that best fits the prompt and record your rationale:

   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 idea flow is explicitly waived under /yolo automation):

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

   chorus_pm_validate_elaboration requires idea:admin. /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 the Proposal

1. Create the empty proposal container:

   chorus_pm_create_proposal({
     projectUuid: "<project-uuid>",
     title: "<feature name>",
     description: "<summary derived from the elaborated idea>",
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })
   

2. Add a tech-design document draft. Capture architecture, data model, API surface, and module contracts (return formats, error patterns, call points) so each task draft can reference a single source of truth:

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

3. Add task drafts incrementally and chain them into a dependsOn DAG with the returned draftUuid of each upstream draft. acceptanceCriteriaItems is required on every draft — at least one non-blank criterion, or the call is rejected. Each criterion must be objectively verifiable by a different agent:

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

   For a DAG of 4 or more tasks, include at least one integration-checkpoint task whose AC requires end-to-end execution of the preceding modules together. The proposal reviewer treats a missing integration checkpoint as a BLOCKER, so add one up front.

4. Validate and fix any reported errors before submitting:

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

5. Submit for review:

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

   Proceed to Phase 2 — you drive the proposal review yourself; nothing reviews it automatically.

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: use your harness's waiting mechanism (the Independent Review pattern below lists the per-harness calls). Your spawn call's 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.

Phase 2: Proposal Review Loop

Run an adversarial review on the submitted proposal using the Independent Review pattern (see below). Loop until the verdict allows approval or you exhaust maxProposalReviewRounds.

Independent Review pattern (framework-neutral). Spawn a read-only sub-agent and have it load the proposal-reviewer-chorus skill (<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md), pass it the proposalUuid and the current review round number, and instruct it to post exactly one VERDICT comment on the proposal. The reviewer's only side effect is that comment; it makes no writes to your project. After it returns, read the verdict via chorus_get_comments.

The exact spawn mechanism is harness-specific — these are EXAMPLES only, not a hard dependency:

• Claude Code: dispatch a sub-agent with the Task/Agent tool, mounting the proposal-reviewer-chorus skill.
• Codex: spawn_agent mounting the skill, then wait_agent; release the thread slot with close_agent afterwards.
• Any other harness: whatever read-only sub-agent primitive it exposes.

Inline self-review fallback (no sub-agents available). If your harness cannot spawn a sub-agent, perform the review inline as the main agent: read proposal-reviewer-chorus, follow its procedure against this proposal (fetch the proposal section: "full", the idea, and the elaboration; audit documents and task drafts; classify findings as BLOCKER vs NOTE), and post your own VERDICT comment via chorus_add_comment. The verdict semantics below are identical in either mode.

This is the canonical pattern; chorus (<BASE_URL>/skill/chorus/SKILL.md) documents it canonically — describe it inline here so yolo is self-contained.

Review loop:

round = 1
loop:
  # 1. Spawn the reviewer (Independent Review pattern above) with proposalUuid + round.
  #    Fallback: inline self-review as the main agent.

  # 2. Read THIS round's VERDICT comment — posted after your dispatch, not an older round's.
  comments = chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
  # Find THIS round's "VERDICT:" comment — the one posted after your dispatch, not an older round's.

  # 3. Act on the verdict (three outcomes).

1. VERDICT: PASS or VERDICT: PASS WITH NOTES — approve. Tasks and documents materialize automatically; proceed to Phase 3.

   chorus_admin_approve_proposal({
     proposalUuid: "<proposal-uuid>",
     reviewNote: "PASS from reviewer. <one-line summary of any NOTES>"
   })
   

2. VERDICT: FAIL — read the BLOCKERs from the reviewer comment, reject, revise, and resubmit:

   chorus_pm_reject_proposal({
     proposalUuid: "<proposal-uuid>",
     reviewNote: "FAIL from reviewer. Fixing BLOCKERs: <list>"
   })
   # Revise drafts to address each BLOCKER:
   #   chorus_pm_update_document_draft({ ... })
   #   chorus_pm_update_task_draft({ ... })
   chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
   round += 1
   # Re-run the Independent Review for the next round (pass round = current number).
   

3. Max rounds escalation. Loop up to maxProposalReviewRounds (default 3). If exhausted with unresolved BLOCKERs:

   STOP: "Proposal review failed after 3 rounds. Remaining BLOCKERs: <list>.
          Human review needed. Proposal UUID: <proposal-uuid>."
   

4. No new VERDICT for this round? Apply step 3 of the Reviewer contract, reviewing the proposal yourself if the reviewer stays silent.

Phase 3: Execution (Wave-Based)

After approval, tasks exist in open. Execute them in dependency-ordered waves. A wave is the current set of unblocked tasks; verifying a wave (Phase 4) unblocks the next.

wave = 1
loop:
  # 1. Find tasks whose dependencies are all resolved (done/closed).
  unblocked = chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })

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

  if no unblocked tasks and some tasks not done:
    break with escalation report   # stuck: tasks failed review or are circularly blocked

  # 2. Dispatch one worker per unblocked task (see worker dispatch below).
  # 3. Wait for workers to reach `to_verify`.
  # 4. Run Phase 4 verification for this wave's tasks.
  wave += 1
  # 5. Loop: re-check chorus_get_unblocked_tasks for newly unblocked tasks.

Worker dispatch (framework-neutral). For each unblocked task, dispatch a worker sub-agent that follows the developer workflow (develop-chorus, <BASE_URL>/skill/develop-chorus/SKILL.md): claim -> in_progress -> implement -> report_work -> self-check AC -> submit_for_verify. The worker prompt needs:

• taskUuid (required)
• projectUuid (required, for context lookups)
• An explicit instruction to follow the develop-chorus skill and to exit after chorus_submit_for_verify so the main agent can run verification.

The spawn mechanism is harness-specific — EXAMPLES only:

• Claude Code: one sub-agent per task via the Task/Agent tool (parallel within the wave).
• Codex: spawn_agent per task, then wait_agent; close_agent each worker after it returns.
• Optionally create a chorus_create_session per worker for observability and chorus_close_session it when the worker finishes.

Sequential main-agent fallback. If sub-agents are unavailable, or parallel execution is impractical (rate limits, token budget, simpler debugging), execute each unblocked task yourself, sequentially, as the main agent:

for each task in unblocked:
  chorus_claim_task({ taskUuid: "<task-uuid>" })
  chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })
  # ... read context (task, proposal documents, upstream deps), implement, run tests ...
  chorus_report_work({ taskUuid: "<task-uuid>", report: "..." })
  chorus_report_criteria_self_check({ taskUuid: "<task-uuid>", criteria: [ ... ] })
  chorus_submit_for_verify({ taskUuid: "<task-uuid>", summary: "..." })
  # Then run Phase 4 verification for this task before moving on.

The fallback is slower (no parallelism) but completes the same pipeline.

Phase 4: Verification Loop

After each wave's workers reach to_verify, verify their tasks using the Independent Review pattern — the same neutral mechanism as Phase 2, pointed at the task-reviewer-chorus skill.

Independent Review pattern (framework-neutral). Spawn a read-only sub-agent and have it load the task-reviewer-chorus skill (<BASE_URL>/skill/task-reviewer-chorus/SKILL.md), pass it the taskUuid and the current review round number, and instruct it to post exactly one VERDICT comment on the task. The reviewer's only project side effect is that comment (it may run read-only tests/build/lint, but never writes). After it returns, read the verdict via chorus_get_comments.

The exact spawn mechanism is harness-specific — EXAMPLES only:

• Claude Code: dispatch a read-only sub-agent with the Task/Agent tool, mounting the task-reviewer-chorus skill.
• Codex: spawn_agent mounting the skill, then wait_agent; close_agent afterwards to release the thread slot.

Inline self-review fallback (no sub-agents available). Perform the review inline as the main agent: read task-reviewer-chorus, follow its procedure (fetch the task, its AC, comments, and the proposal section: "documents"; run the project's test/build/lint; verify each AC independently; classify BLOCKER vs NOTE), and post your own VERDICT comment via chorus_add_comment.

Verification loop, per task in the wave:

for each task in wave_tasks:
  t = chorus_get_task({ taskUuid: "<task-uuid>" })
  if t.status != "to_verify":
    continue   # worker did not submit; handle in a later wave or escalate

  # Spawn the task reviewer (Independent Review pattern) with taskUuid + round.
  # Fallback: inline self-review.

  comments = chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
  # Find THIS round's "VERDICT:" comment — the one posted after your dispatch, not an older round's.

Act on the verdict — three outcomes:

1. VERDICT: PASS — all AC verified, no issues. Mark AC and verify:

   chorus_mark_acceptance_criteria({
     taskUuid: "<task-uuid>",
     criteria: [ { uuid: "<ac-uuid>", status: "passed", evidence: "<from reviewer>" } /* ... */ ]
   })
   chorus_admin_verify_task({ taskUuid: "<task-uuid>" })   # -> done, unblocks dependents
   

2. VERDICT: PASS WITH NOTES — minor, non-blocking notes only. Still mark AC and verify (same two calls as above).

3. VERDICT: FAIL — BLOCKERs found. Do NOT verify. Reopen for rework; the task returns to in_progress (its AC reset to pending) and is picked up in the next wave:

   chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
   chorus_add_comment({ targetType: "task", targetUuid: "<task-uuid>",
                        content: "Reopened. BLOCKERs to fix: <list>" })
   

Max rounds escalation. Track review rounds per task via maxTaskReviewRounds (default 3). If a task has been reopened 3 times and still FAILs, skip it and flag for human escalation — do not halt the whole pipeline for one stuck task:

ESCALATE: "Task '<title>' failed review after 3 rounds. Last BLOCKERs: <list>.
           Manual intervention needed. Task UUID: <task-uuid>."

No new VERDICT for this round? Apply step 3 of the Reviewer contract, reviewing the task yourself if the reviewer stays silent.

After verifying every task in the wave, return to Phase 3 and re-run chorus_get_unblocked_tasks for newly unblocked tasks. Repeat until no tasks remain.

Phase 4.5: Code-Review Gateway (mandatory pre-ship)

Once every task of the idea's proposal is verified (done) — Phase 3 finds no more unblocked tasks and none remain non-terminal — run the final ship-time code-review gateway before the Phase 5b completion report. This is the same Independent Review pattern as Phases 2 and 4, pointed at the code-reviewer-chorus skill — but it reviews the whole Idea's aggregate code change (across all tasks), not a single task, and posts its verdict on the Idea.

Independent Review pattern (framework-neutral). Spawn a read-only sub-agent and have it load the code-reviewer-chorus skill (<BASE_URL>/skill/code-reviewer-chorus/SKILL.md), pass it the ideaUuid and the current review round number, and instruct it to post exactly one VERDICT comment on the idea. It reviews cross-task integration, architecture/convention consistency, security, regression/performance, and feature-level test coverage — dimensions a single-task review cannot see — and may run read-only tests/build/lint, but never writes. After it returns, read the verdict via chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" }).

• Claude Code: dispatch a read-only sub-agent with the Task/Agent tool, mounting the code-reviewer-chorus skill.
• Codex: spawn_agent with the code-reviewer-chorus skill and the ideaUuid.

Inline self-review fallback (no sub-agents available). Perform the review inline as the main agent: read code-reviewer-chorus, follow its procedure (fetch the idea, its approved proposals + documents + tasks; infer the aggregate diff from task reports + git log/diff; review the six whole-feature dimensions; run the project's build/test), and post your own VERDICT comment on the idea.

Act on the verdict:

• VERDICT: PASS / PASS WITH NOTES — the feature is cleared to ship. Proceed to Phase 5 / 5b.
• VERDICT: FAIL — do NOT ship. Read the BLOCKERs, then fix them via the quick-dev workflow (<BASE_URL>/skill/quick-dev-chorus/SKILL.md): call chorus_create_tasks with proposalUuid set to the current approved proposal so the fix tasks attach to it (not standalone) — do not reopen the already-verified tasks. Group related small BLOCKERs into one cohesive task by default; split only materially large or independently testable fixes. Drive every fix task through Phase 3 → Phase 4, including AC self-check, independent task review, and admin verification. Re-spawn the code-reviewer only after every fix task is successfully done; a failed or cancelled fix task, stop the automatic loop and escalate. Loop bounded by maxCodeReviewRounds (default 3; 0 = unlimited).

ESCALATE: "Idea '<title>' failed code review after 3 rounds. Last BLOCKERs: <list>.
           Manual intervention needed. Idea UUID: <idea-uuid>."

No new VERDICT for this round? Apply step 3 of the Reviewer contract, reviewing the idea's aggregate change yourself if the reviewer stays silent.

The gateway is behavioral, consistent with the other two reviewers: its verdict is advisory and does not change the Idea's stored status; the orchestrator honors it. It runs before the completion report so the report is never written while a FAIL is outstanding.

Phase 5: Report

When all waves complete, output a markdown summary:

## Yolo Complete

**Project:** <project-name> (<project-uuid>)
**Proposal:** <proposal-title> (<proposal-uuid>)
**Idea:** <idea-title> (<idea-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
- Idea Completion Report: <document-uuid>   (from Phase 5b)

Phase 5b: Idea Completion Report (mandatory)

A successful yolo run always finishes the Idea. Call chorus_create_report exactly once, with proposalUuid set to the last verified proposal. The call requires title (a short report title) plus content; content's parameter description carries the three-section template (## Summary / ## Decisions / ## Follow-ups) — follow it. Surface the returned documentUuid in the Phase 5 summary table. Skipping this is a protocol violation.

Order: write the completion report only after the Phase 4.5 code-review gateway returns PASS / PASS WITH NOTES. Never write it while a code-review FAIL is outstanding — the report is a ship-time summary, and the gateway is what clears the feature to ship.

result = chorus_create_report({
  proposalUuid: "<last-verified-proposal-uuid>",
  // ... follow the content parameter's section template ...
})
# Surface result.documentUuid in the Phase 5 summary.

Error Handling

Tips

• Keep the prompt detailed — richer input yields a stronger proposal and fewer review rounds.
• The proposal reviewer is your quality gate — repeated FAILs usually mean the prompt is too vague; tighten it and rerun.
• Watch the wave count — if tasks keep getting reopened, interrupt and inspect the reviewer feedback before continuing.
• Prefer sub-agents when available — a fresh read-only reviewer is more adversarial than reviewing your own output inline; use the inline fallback only when you must.
• Everything is audited — elaboration Q&A, reviewer VERDICTs, work reports, and approvals all persist; inspect the Chorus UI for the full history.
• For small, single-step work, prefer quick-dev-chorus (<BASE_URL>/skill/quick-dev-chorus/SKILL.md) — it skips the Idea -> Proposal overhead.
• Sub-agents share your API key — confirm it carries the Prerequisites permissions before starting.

Next

• To create proposals manually: proposal-chorus skill (<BASE_URL>/skill/proposal-chorus/SKILL.md)
• To develop tasks manually: develop-chorus skill (<BASE_URL>/skill/develop-chorus/SKILL.md)
• To review proposals and verify tasks manually: review-chorus skill (<BASE_URL>/skill/review-chorus/SKILL.md)
• For platform overview and shared tools: chorus skill (<BASE_URL>/skill/chorus/SKILL.md)