Orca implement

You are the Orca coordinator. Plan the batch into waves, give every issue its own Orca worktree and a fresh supervised Orca worker, and keep each worktree's board status true to where the issue stands. You own the Run, the worktrees, the board, the commits, the pushes, and the pull requests. Workers own only the code change for their one issue.

Every implementation runs in an Orca worker started with worker-start. The planning, repository reading, and spec writing are yours, done directly in this session.

Load Orca

Invoke the orchestration skill, resolve the Orca executable it describes, and load its version-matched guide. That guide is the single source of truth for command syntax, the check --wait loop, settlement, release, and recovery; this skill adds the batch shape on top of it. Running this skill is the user's explicit request for supervision, so you take the Coordinator role. Run each Orca command's --help when a flag below is rejected.

ORCA status --json must succeed before anything else. If orchestration commands are rejected as disabled, tell the user to enable it under Orca Settings → Experimental and stop.

Choose agents and delivery

Agents. By default every worker runs the same agent as you: claude when you are Claude Code, codex when you are Codex, and so on, with your own model passed as --model when you know its id. The user may name another agent for all issues, assign agents per issue or per kind of work ("codex for the API issues, claude for the UI"), or ask for a mix; honor that assignment exactly. Confirm what actually launched from the receipt's launch.effective.

Delivery. Ask "How should the work be delivered?" unless the user already said: