Chorus

5. Daemon auto-start via chorus agents add

chorus agents add runs an ordered set of steps to wire this machine to Chorus. Its final step — daemon-setup — configures the local Chorus daemon and, opt-in, installs it as a boot-autostart service.

• What it configures. Reusing the same preflight as chorus daemon install, it persists the served working directories (cwds) and the default backend agent into ~/.chorus/daemon.json. Credentials are the connection credentials only — the Chorus URL + API key (cho_…) seeded earlier in the run. chorus agents add never collects or stores model-provider secrets (see the limitation below).
• Opt-in auto-start.
  • Interactive (TTY): it asks "Install & enable the Chorus daemon to auto-start on boot?" — default No. Answer yes to install.
  • Non-interactive (non-TTY, or --yes): it installs the boot service only when you pass --daemon-autostart; otherwise it writes ~/.chorus/daemon.json and leaves starting the daemon to you (chorus daemon).
• Platform support. Auto-start is a real boot service on Linux (systemd --user) and macOS (launchd LaunchAgent) — both start now and at every login. On other platforms (e.g. Windows) it writes the config and prints the manual start steps instead of installing anything.
• Idempotent. Re-running when the service is already installed reports it as already configured and changes nothing.
• Manage it. chorus daemon status | stop | restart | logs transparently delegate to the installed supervisor (systemctl --user on Linux, launchctl on macOS); with no service installed they operate on the chorus daemon -d pidfile/log as before.

⚠️ Provider credentials on a boot service (important). A boot-launched daemon (systemd --user or launchd) starts in a clean environment and does not inherit your shell-exported model-provider secrets (ANTHROPIC_API_KEY, AWS_* / CLAUDE_CODE_USE_BEDROCK, etc.). Chorus keeps daemon.json to the Chorus connection credentials only, so you must supply provider credentials to the service's environment yourself:

• Linux (systemd): add a drop-in ~/.config/systemd/user/chorus-daemon.service.d/env.conf containing [Service] + Environment=ANTHROPIC_API_KEY=… then systemctl --user daemon-reload && systemctl --user restart chorus-daemon.service; or place the vars in ~/.config/environment.d/*.conf.
• macOS (launchd): launchctl setenv ANTHROPIC_API_KEY … (before load), or add an EnvironmentVariables dict to ~/Library/LaunchAgents/com.chorus.daemon.plist.

Without this, a boot-started daemon reaches Chorus fine but its spawned agents may fail to reach the model provider.

Execution Rules

1. Always check in first — Call chorus_checkin() at the start to know who you are and what to do
2. Stay in your role — Only use tools available to your role
3. Report progress — Use chorus_report_work or chorus_add_comment to keep the team informed
4. Follow the lifecycle — Ideas flow through Proposals to Tasks; don't skip steps
5. Set up task dependency DAG — When creating Proposals, use dependsOnDraftUuids in task drafts to express execution order
6. Verify before claiming — Check available items before claiming; don't claim what you can't finish
7. Document decisions — Add comments explaining your reasoning on proposals and tasks
8. Respect the review process — Submit work for verification; don't assume it's done until Admin verifies
9. Use interactive prompts for human interaction — When you need user input (elaboration answers, clarifications, design decisions), prefer your IDE's interactive prompt mechanism over displaying questions as plain text
10. Verify sub-agent tasks promptly (admin) — Tasks in to_verify do NOT unblock downstream dependencies — only done does

Status Lifecycle Reference

Idea Status Flow

open --> elaborating --> proposal_created --> completed
  \                                            /
   \--> closed <------------------------------/

Task Status Flow

open --> assigned --> in_progress --> to_verify --> done
  \                                                 /
   \--> closed <-----------------------------------/
         ^                    |
         |                    v
         +--- (reopen) -- in_progress

Proposal Status Flow

draft --> pending --> approved
                 \-> rejected --> revised --> pending ...
approved --> draft  (via revoke — cascade-closes tasks, deletes documents)

Independent Review

Chorus uses independent, read-only adversarial reviewers at three gates: before a proposal is approved, before a task is verified, and before an Idea's code ships (the final aggregate gateway). The reviewer's job is to find what is wrong — not to rubber-stamp. Its output is advisory: it informs the orchestrator's decision but does not by itself approve, reject, verify, reopen, or ship anything.

This is the single canonical description of the reviewer pattern. The develop-chorus, review-chorus, and yolo-chorus skills all point back here rather than redefining it.

The Pattern

1. Spawn a read-only sub-agent that loads one of the three reviewer skills:
   • proposal-reviewer-chorus (<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md) — for reviewing a proposal before approval. Pass it the proposalUuid.
   • task-reviewer-chorus (<BASE_URL>/skill/task-reviewer-chorus/SKILL.md) — for reviewing a task before verification. Pass it the taskUuid.
   • code-reviewer-chorus (<BASE_URL>/skill/code-reviewer-chorus/SKILL.md) — the final ship-time gateway: reviews an Idea's aggregate code change (the whole feature across all its tasks) after its last task is verified, before the code ships. Pass it the ideaUuid and the review round number. Posts its VERDICT on the Idea.
2. The reviewer audits independently and posts exactly one structured VERDICT comment on the proposal/task/idea via chorus_add_comment. The comment ends with one literal verdict string: VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL.
3. Read the verdict and act. Fetch the comment with chorus_get_comments({ targetType, targetUuid }), read the BLOCKER / NOTE findings, then make the call:
   • PASS / PASS WITH NOTES → proceed (approve the proposal / verify the task / ship the feature), addressing NOTEs at your discretion.
   • FAIL → do not proceed; route the BLOCKERs back for a fix (reject/revise the proposal, reopen/rework the task, or — for the code-review gateway — add new fix tasks to the approved proposal and re-run once they are done), then re-review. The cleanest way to run those code-review fix tasks is 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), then group related small BLOCKERs by default and split only materially large or independently testable fixes. Never reopen completed tasks or apply untracked fixes. Require AC self-check, independent task review, and admin verification for every fix; re-run aggregate review only after all are successfully done. A failed or cancelled fix stops the loop and escalates, while maxCodeReviewRounds remains authoritative.

The verdict is advisory: even a FAIL does not hard-block, and a PASS does not auto-approve. A human/admin (or, under /yolo, the automated orchestrator) makes the final decision. The code-review gateway in particular is a behavioral gate — it does not change the Idea's stored status; the orchestrator honors its verdict.

First-Principles Alignment (a stage-tailored instruction in all three reviewers)

Beyond their local checks, every reviewer also verifies top-down that the work still serves the original Idea's intent. Each one first resolves the Idea from the entity it is reviewing — proposal-reviewer → the proposal's inputUuids[0]; task-reviewer → chorus_get_task, then that task's proposal's inputUuids[0]; code-reviewer → the ideaUuid it was given (skip the dimension if there is no attached Idea) — then reads it with the existing reads: chorus_get_idea (content), chorus_get_elaboration (resolved decisions, each carrying answeredBy.type), and chorus_get_comments({ targetType: "idea" }) (each comment carrying author.type). It builds the authoritative baseline of original intent from human input alone: the Idea content + elaboration answers where answeredBy.type == "user" + comments where author.type == "user". Agent-answered elaboration and agent-authored comments are audit context only — they can never expand, shrink, or override the baseline, so a drifting agent cannot self-authorize by self-answering a YOLO elaboration or posting its own Idea comment. The work under review is checked against that baseline for three drift types:

• Scope creep — work beyond the original intent.
• Requirement loss / shrink — intent the baseline states, quietly dropped or reduced.
• Semantic drift — the work passes its acceptance criteria but misses the baseline's point.

Any drift is a BLOCKER → VERDICT: FAIL / reject — unless it is traceable to a human authorization: a comment with author.type == "user", an elaboration decision with answeredBy.type == "user", or an explicit human override at the gate. An agent-authored or agent-answered entry never authorizes — a drifting agent cannot self-clear by posting its own comment. When a reviewer downgrades a deviation on this escape hatch, it downgrades to a NOTE and cites the specific human entry it relied on, so the decision is human-auditable. If the entity has no attached Idea (e.g. a document-input proposal), the alignment dimension is skipped. This is one labeled part of the existing VERDICT — not a separate report.

Spawn Mechanism Is Harness-Specific

How you spawn the read-only sub-agent depends on your agent harness — give it the reviewer skill plus the target UUID and instruct it to post a single VERDICT comment. Then wait for it using your harness's own waiting mechanism, and read THIS round's VERDICT: comment for the entity under review with chorus_get_comments — the comment posted after your dispatch, not an older round's. Do not advance the pipeline before you have read that comment. Concrete examples:

• Claude Code — use the Task / Agent tool to launch a sub-agent that loads task-reviewer-chorus (or proposal-reviewer-chorus / code-reviewer-chorus) and pass the taskUuid / proposalUuid / ideaUuid.
• Codex — use spawn_agent with the reviewer skill and the target UUID.
• Other harnesses: use whatever sub-agent / sub-task primitive they expose.

Inline Self-Review Fallback

When sub-agents are not available in your harness, run the review inline yourself: load the relevant reviewer skill's procedure (proposal-reviewer-chorus, task-reviewer-chorus, or code-reviewer-chorus), audit the proposal/task/idea against its checklist with the same adversarial posture, and post the single VERDICT comment yourself before acting on it. A same-agent self-review is weaker than a fresh independent reviewer, but it is far better than skipping the gate.

Skill Routing

This is the core overview skill. For stage-specific workflows, download and read the appropriate skill:

Getting Started

1. Call chorus_checkin() to learn your role and assignments
2. Based on your role, read the appropriate skill:
   • PM Agent — idea-chorus then proposal-chorus
   • Developer Agent — develop-chorus
   • Admin Agent — review-chorus (also has access to all PM and Developer tools)