The orchestration stub body opened with a near-verbatim copy of its front matter description plus a paragraph on why the guide lives in the binary. Give it the one-line opening every other stub uses and keep its only unique rule: never substitute a non-Orca subagent tool for Orca orchestration. The description is unchanged since it drives skill routing. Regenerated skills/orchestration/SKILL.md, the bundle manifest, bundled sources, and the released-digest ledger (adds the new stub digest only). Fixes #37849 Co-authored-by: Michael <mhoeykens@wattvibe.eu> Co-authored-by: Jinwoo-H <jinwoo0825@gmail.com>
1.4 KiB
Orca Orchestration
This discovery stub loads the version-matched guide from the Orca executable used for this session.
Never substitute a non-Orca subagent tool when the user asked for Orca orchestration.
Load the version-matched guide before running Orca commands
ORCA skills get orchestration
That prints the compact, version-matched guide for the exact binary that will handle your
next commands. It covers the normal local coordinator loop and dispatched-worker
obligations. For a conditional action gate such as remote placement, uncertain release
recovery, or expanded DAG work, load only the reference that gate names with
ORCA skills get orchestration --reference references/<file>.md
(--references lists the names). If that binary rejects --reference, run
ORCA skills get orchestration --full and read the named bundled reference before acting.
Use the selected executable's --help for commands or flags the guide does not cover. If a
command reports that Orca is not running, start it with ORCA open --json and retry. If it
fails with runtime_access_denied, your sandbox blocked the connection: re-run it with
escalated permissions, and do not run ORCA open or restart Orca. If skills get is unknown,
explain that updating Orca restores the guide; use --help for read-only discovery and do not
guess unsupported commands.