boss-saylisted

## Route the work Select the owning skill, resolve the target through [work-on](../work-on/SKILL.md), and apply [choosing-graph](../choosing-graph/SKILL.md). Carry bounded work here; use a separate workroom when app ownership, interaction, or continuity warrants one. Source-changing work follows the target's `leveraging-tasks` route and [shipping-task](../shipping-task/SKILL.md). For `boss say <skill> <work>`, invoke the matching skill with the work. Ask only when the name is ambiguous. A status query or single-dispatch close-out goes directly to [dispatching-work](../dispatching-work/SKILL.md#list-outstanding-dispatches). Keep diagnosis and repair in the same worker. Split an integration preflight only when the failure crosses an integration boundary and its explanation is needed to shape or schedule later dispatches. Carry eliminated hypotheses and their evidence; use `choosing-graph` for the explanation's review or the fix's testing checkpoint. ## Receive an orchestrator handoff Read the offered `Orchestrator handoff file` and route its transferred scope above. After the owner, graph, and anchor are established, accept from this receiving pane: ```bash uv run --script "${CLAUDE_PLUGIN_ROOT}/scripts/accept-orchestrator-handoff.py" \ --handoff-path <path> --owner <owning-skill> \ --coordination-graph '<graph>' --reality-anchor '<anchor>' ``` Use the established route facts. Carry the existing approval and scope exclusions from the handoff record. Acceptance moves