git:20261022.f1bb2a9 to git:20261023.b1b8efe

23 added, 37 removed. Audit A to A.

---

name: rumo-agent-collaboration

description: Use when the user asks to delegate, transfer, or relay work to another agent CLI or model, such as Codex, Claude Code, pi, Aider, or Gemini ("give this part to pi", "交给 pi 执行"), to use Orca for collaboration, or to resume a recorded run. For a named external CLI review, also load rumo-review; use rumo-review alone when no external route is named. Use rumo-handoff for a handoff document and rumo-plan to split an agreed plan. Do not use for this client's own subagents, such as "start several subagents".

---

# Rumo Agent Collaboration

- Start a different agent, give it a bounded piece of work, and keep it clear at every moment who owns the task.

+ Hand a bounded piece of work to another agent where the user can see it, end your turn, and accept the result on evidence.

## Scope

- This skill governs only the agents it starts. The client's own subagents, whether it uses them by itself or because the user asked for several, follow the client's rules and need nothing from this skill. When a relay or transfer in this skill runs one step through a native subagent, the single-owner rules here still apply to that step.

- For a named external CLI review, use rumo-review for review standards and this skill for execution and records. Read rumo-review before writing the review brief; when it is not installed, follow [references/external-cli.md](references/external-cli.md) alone. Read [references/trigger-examples.md](references/trigger-examples.md) when checking selection boundaries with neighboring skills.

- ## Modes

- - **Delegate**: you stay the owner. The other agent does one bounded job and reports; you check the result before using it. Handing over part of a task is delegation: you still own the whole.

- - **Transfer**: the other agent becomes the owner of the whole task. Once it confirms it has taken over, you stop.

- - **Relay**: ownership moves on purpose along a chain, such as develop, review, fix. Each step names the next owner; nobody acts on the task between steps.

- When the request does not make clear whether part or all of the task moves, ask. Free-form agent-to-agent messaging and schedulers that keep running after this conversation are out of scope.

- ## Before Launching

- Settle and write down: the goal and acceptance check, the working directory, which files the agent may write, the access level, the model, and what the user has already authorized.

+ This skill governs only the agents it starts; the client's own subagents follow the client's rules, except that a relay or transfer step run through one keeps the single-owner rules here. Before declaring native subagents available or unavailable, read [references/native.md](references/native.md).

- Never start an agent through this skill unless the user asked for it. When the user named the CLI and the work, that request is the approval: state in one line before launching which CLI and model will run and what content you will send, then launch without asking again. Ask first when the user did not name a route, when you would send content the user did not mention, or when the work needs more access than the request implies.

+ For a named external CLI review, use rumo-review for review standards and this skill for execution and records. Read rumo-review before writing the review brief. [references/trigger-examples.md](references/trigger-examples.md) marks the boundaries with neighboring skills.

- Asking another agent to carry out work that edits files approves writes limited to the files or module the user named. Use `workspace-write` for a documented directory restriction, or `native-write` for native CLI permissions without promised directory isolation. A worktree is not a sandbox. Before a native-write launch, state any default automatic approval and whether shell tools are available. Wider access, such as shell access for pi, needs its own approval. Never give the receiver more access than you have, and never pass a flag that bypasses its sandbox, approvals, or tool limits. Commits, pushes, deployments, and dependency installs keep the approvals their own skills require; a launch does not grant them.

+ ## Ownership

- ## Choose The Route

+ You stay the owner: treat any request to hand work to another agent as delegation, whatever verb it uses, such as "交给" or "交接给". Transfer ownership only when the user says this session should step away, such as "let it take over; you're done here". In a relay (develop, review, fix), each step names the next owner, and nobody acts on the task between steps. Free-form agent-to-agent messaging and schedulers that keep running after this conversation are out of scope.

- Before declaring native subagents available or unavailable, read [references/native.md](references/native.md). Do not infer availability from the CLI name, version, or an installed package alone. Check child permissions separately; parent read-only access does not prove child read-only access.

+ ## Authorization

- - Follow the route, client, or model the user names. When the model is named only by a fragment, such as "mimo", resolve it with the CLI's own model listing; when several models match, ask the user which one instead of picking.

- - For another installed CLI, read [references/external-cli.md](references/external-cli.md) and use `scripts/agent_run.py`, resolved from this skill's directory. Each CLI needs an adapter; `agent_run.py list` shows which exist and whether each was verified. Official documentation may establish a write mode while `verified` stays null; describe it as untested, not locally verified.

- - Before the first launch through an unverified adapter, or one written in this task, run `agent_run.py show` and show the user the full command and known limits. Unverified status alone does not require repeated approval. Apply the authorization rules above; when `check` fails, stop.

- - For a CLI with no adapter, read [references/adapters.md](references/adapters.md), write one from that CLI's `--help` or official documentation in the user adapter directory, and show it the same way. A CLI without a confirmed read-only mode cannot have an adapter.

- - Transfer only to an agent that keeps running after you stop: a background session the client provides, an Orca terminal, or an external CLI session the user resumes. A native subagent tied to this conversation can take a delegated step, never a transfer; see [references/native.md](references/native.md).

- - One-turn adapters serve delegation or relay only; do not transfer ownership without a resumable session.

- - When Orca is the route the user picked, or the only one that can transfer, read [references/orca.md](references/orca.md).

- - When the route is unavailable or not signed in, report the blocker. Do not switch route, model, or access level on your own.

+ Never start an agent through this skill unless the user asked for it. When the user named the CLI and the work, that request is the approval: state in one line before launching which CLI, model, and effort will run and what content you will send, then launch. Keep it to that line; do not ask again. A configured `delegate` lane counts as a named CLI. Ask first when the user named no route and none is configured, when you would send content the user did not mention, or when the work needs more access than the request implies.

- Routes not exercised end to end in this repository are untested; say so when you use one.

+ - Pick read-only unless the work edits files; asking for edits approves writes limited to the files or module the user named. Use `workspace-write` only where the adapter documents a directory restriction. `native-write` has no directory isolation: state its default automatic approval and whether shell tools are available. A worktree is not a sandbox.

+ - When the work itself means running commands, such as tests or a build, the request approves shell access for that work: say in the same line that commands run automatically without a directory sandbox, where the agent may write, and what it must not do. Shell access the work does not need, such as shell for a review, needs its own approval; ask at most once per launch.

+ - Never give the receiver more access than you have, and never pass a flag that bypasses its sandbox, approvals, or tool limits. Commits, pushes, deployments, and dependency installs keep the approvals their own skills require.

## Workflow

- 1. Prepare the brief: goal, scope, the files to read, the check that proves it done, and the stop conditions. Give the task, not your reasoning; for a transfer, write the brief in the structure of `rumo-handoff`.

- 2. Isolate writers. Two agents never write the same working tree at once; give a parallel writer its own worktree from a recorded base. Uncommitted changes do not appear in a new worktree: tell the receiver how it gets them, and do not commit them just to move them unless the user approves.

- 3. Launch once and record the run: route, session or run ID, working directory, model, and access. When you cannot tell whether a turn was delivered, check the recorded session before sending anything again.

- 4. Wait without polling when the client can notify you; otherwise wait once with a long enough timeout, or end your turn as described next. A timeout is not a failure of the task: check the session before deciding. Completion notification stays the first choice: when you launched the run as a background command whose exit this client reports to you, rely on that report, not on the user. Only when no notification can reach you, because this client cannot notify or the receiver runs where it cannot watch, such as an Orca terminal, a client background session, or a terminal the user started, you may end your turn after the launch and stay the owner. Before ending, tell the user where the receiver runs, where its result can be read, and what to tell you when it finishes. Until then, do not touch its write scope.

- 5. Accept results on evidence. When the user reports that the receiver finished, read its result and check the working tree before accepting it. Rerun the check yourself, review the changed files, and record the decision with `agent_run.py record` or in your report. A result that arrives after the task was transferred is input for the new owner, not an action for you.

- 6. On transfer: confirm the receiver acknowledged the brief and named its next step, record the transfer, tell the user how to reach the new owner, then stop changing that task.

+ 1. **Brief.** Write the goal, scope, files to read, the check that proves it done, and the stop conditions to a file outside the repository. Give the task, not your reasoning; for a transfer, use the structure of `rumo-handoff`.

+ 2. **Isolate writers.** Two agents never write the same working tree at once; give a parallel writer its own worktree from a recorded base. Uncommitted changes do not appear in a new worktree: tell the receiver how it gets them, and do not commit them just to move them unless the user approves.

+ 3. **Launch once, where the user can see it.** Follow the route, model, and effort the user names. For anything they leave out, use the user's configuration: `scripts/agent_config.py lanes delegate` when no CLI is named, taking the lane whose `use` label fits the work and otherwise the first, and the configured lane's model and effort when the named CLI has one; pass them as `--model`, `--effort`, and `--executable` when the lane has one. Exit 3 means nothing is configured: ask, and mention that `rumo-setup` saves the choice.

+ - Another installed CLI runs through `scripts/agent_run.py`, resolved from this skill's directory; the Quick Start in [references/external-cli.md](references/external-cli.md) has the commands. `start` checks the CLI itself and runs without a window; `watch` shows its progress. Read-only work runs this way. A CLI with no adapter needs one first ([references/adapters.md](references/adapters.md)); a CLI without a confirmed read-only mode cannot have an adapter. Do not call an adapter tested end to end unless its `verified.live_run` is true.

+ - Work that edits files or runs commands goes to an Orca terminal when Orca is installed ([references/orca.md](references/orca.md)), otherwise to `agent_run.py open`, a CLI window the user can type into. When the CLI has no interactive template, use `start` and say why.

+ - When the route is unavailable, not signed in, or refused, report the blocker. Do not switch route, model, or access level on your own.

+ - When you cannot tell whether a turn was delivered, check the recorded session before sending anything again.

+ 4. **Tell the user and end your turn.** In one short message: where the receiver runs, where the result will be, and what to tell you when it finishes; for `start`, add the `watch` command that shows its progress, and when `survives_caller` is not true, that closing this session may also stop the receiver. Leave the full report for acceptance. When this client runs background commands and reports their exit, run `start`, or `agent_run.py wait` after `open`, that way and rely on that report, not on the user; `open` returns once the window opens, not when the work is done. Otherwise add `--detach` to `start`, or after `open` wait for the user. While the receiver runs, do not read its events, logs, or session files and do not post progress updates. Until you accept the result, do not touch its write scope.

+ Client-specific (Claude Code): when both sides are Claude Code, you may instead subscribe once to the receiver's idle notice through cross-session messaging, using the run ID as its session name.

+ 5. **Accept on evidence.** When the user reports that the receiver finished, read its result and check the working tree before accepting it. After a visible window closes, get the report by resuming the session headlessly with a short request for the final report and the changed files. Rerun the check yourself and record the decision with `agent_run.py record`, or in your report for Orca and native routes. A timeout is not a failure of the task: check the session before deciding.

+ 6. **Transfer.** Only to an agent that keeps running after you stop, never to a native subagent tied to this conversation; do not transfer ownership without a resumable session. Confirm the receiver acknowledged the brief and named its next step, record the transfer, tell the user how to reach the new owner, then stop changing that task. A result that arrives later is input for the new owner, not an action for you.

To continue in a later conversation, read [references/records.md](references/records.md) and reconcile the record with the real session and files first.

## Stop Conditions

- Do not launch a disabled adapter, including the bundled Gemini and OpenCode declarations. See [references/adapters.md](references/adapters.md) for their permission gaps.

- - The user has not asked for the launch, or it needs content or access beyond what the user approved.

- Two agents are writing the same files: stop both where you can, and report.

- A record and the real state disagree: report the gap; do not start a second writer.

- Native approval needs interaction that this turn cannot provide: stop and return the blocker; never switch to automatic approval to finish.

- Cancel only runs this task started; never stop a process the record cannot prove is yours.

## Report

- Route, CLI and version, model, run or session ID, access level, what was sent, the result and how you checked it, the current owner, and the exact command to resume.

+ At acceptance: route, CLI, version and model, run ID, access, how it ran, what was sent, the result and how you checked it, the current owner, and the command to resume.