Coagent8 Delegate

---
name: coagent8-delegate
description: Hand a well-defined code change to another local coding agent (Codex, Claude Code or Antigravity) through the CoAgent8 delegate tool, then check what it changed. Use when the user asks to delegate, hand off or parallelize coding work, or names CoAgent8 delegate. Not for questions or reviews, which consult and review answer read-only.
---

# CoAgent8 delegate

The other agent changes files in the workspace. You stay responsible for the
result: you check what it changed, run the checks and get it reviewed. This
skill grants no permission. Commit, push, merge, deploy and publish only with
the user's authority; the delegated agent never does.

1. **Fit.** Delegate a change you can describe and verify: a function with its
   tests, a bug fix with a reproduction, a mechanical refactor. Do not delegate
   a decision the user has not made.
2. **Clean start.** Run `git status` first. Commit or set aside work you want
   kept apart: the result marks files that already had uncommitted changes, but
   the agent may still edit them.
3. **Task.** Write a self-contained `task`: what to change, where and the
   acceptance criteria. The agent has not seen this conversation. Name files and
   symbols instead of pasting them; it reads the workspace itself.
4. **Scope and checks.** Put the paths it may change in `scope` (whole path
   segments: `src` does not cover `src-old`) and the commands that prove the
   change in `checks`, such as `npm test`. Omit `scope` only when the whole
   workspace is fair game.
5. **Model.** Leave `backend`, `model` and `reasoning_effort` unset unless the
   user named one or a price limit. The approval rules of `coagent8-consult`
   apply unchanged: the server asks the user for expensive or unpriced models.
6. **While it runs.** The call returns `task_handle`, `session_handle` and
   `wait_argv` as soon as the agent runs, and it goes on after the call. With
   `wakeup: background_wait`, start `wait_argv` verbatim as a background command
   (with `wait_env` when present): you are woken when it exits, and its output is
   the result. With `wakeup: none`, read it later with the `session` tool, action
   `task`. Do not edit this work tree meanwhile. `cancel` with the `session_handle`
   stops the agent; stopping the wait does not. Pass `mode: "sync"` only when you
   would wait anyway.
7. **Read the result.** The agent's report comes first, then the block
   "Observed by CoAgent8", which the server read from Git before and after the
   turn. Trust the block over the report. Treat every warning as a finding:
   changes outside the scope, files that had uncommitted changes before, and a
   moved HEAD (a commit or branch switch the agent was told not to make).
8. **Verify.** Read the diff. Without `loop`, run the checks yourself and record
   their exit codes. The agent's PASS is its claim, not evidence, and NOT_RUN is common:
   Antigravity runs no commands, and Codex on Windows cannot run test runners
   that start processes from Node.
9. **Fix rounds.** For corrections pass the result's `session_handle` with a
   `task` naming what to fix. A delegate session continues only with delegate.
10. **Review.** Use `coagent8-review` in a separate session, ideally another
   backend, with the acceptance criteria and your check results in
   `instructions`. The author of a change never approves it.

**Server loop.** With `loop: true` the server itself runs `checks`, then a read-only
review on another backend, returns failures to the agent for up to two fix rounds,
and reports all of it once, in the block "Loop by CoAgent8". Use it when you would
otherwise supervise those rounds. Each check is one command with arguments, without
a shell, and runs with the user's rights, outside any sandbox, on code the agent may
have changed: tell the user, because the server asks them on a form unless the exact
command is in `allowedChecks` of their configuration. You cannot approve it. Some
clients answer the form without showing it, so when the refusal says the client
declined or closed it, do not say who refused: ask the user whether they saw the
form, and tell them that listing the command in `allowedChecks` avoids it. Steps 8
to 10 then shrink to reading the diff: only `passed` means the checks and the review
went through, and the review is still another model's opinion. `needs_input` means
a turn needed the user's approval: the change stays for you.

**Parallel agents.** Several agents can work at once when their `scope`s do not
overlap; an overlapping start is refused with `SESSION_BUSY`, also from another
client. No `scope` or `loop: true` takes the whole work tree. Pass the first
result's `root_handle` to each further delegate, so they share the user's limits
(`ROOT_LIMIT` when one is reached: wait, or ask the user; you cannot raise it) and
`cancel` with `root_handle` stops them all. `session` with `action: root` shows them.
Start one wait per task. Split only work that does not touch the same files: a scope
is checked at the start and observed at the end, not enforced, so read each result's
warnings. A note that another worker held a path means either may have changed it.
Each agent's own checks see the others' half-finished work, so run the checks and
the review once on the whole result, after all have finished. A finished agent
does not make the work accepted. Work that cannot be split by path needs its own
Git worktree on its own branch (`git worktree add ../repo-a -b task-a`) and
`workspace_path`; integrate the branches yourself. Create worktrees only where
the user agrees to them.

**Coordinator.** With `coordinate: true` an agent plans a larger objective and the server runs its workers, all on Codex or
Claude Code, not Antigravity: put the objective and acceptance criteria in `task`, and the
paths its workers may hold in `scope`. You get a `task_handle` as usual, and its result
is the coordinator's report and the list of workers. Check each worker's result with
`session`, action `task`, and review the whole change yourself: a coordinator accepts
nothing. Its workers cannot show a form, so list the checks of their `loop` in
`allowedChecks` first, and leave out `checks`, `loop` and `mode: "sync"` on the
coordinator itself. `cancel` with its `session_handle` or `root_handle` stops the workers.
After an `interrupted` coordinator, call again with `coordinate: true`, its
`session_handle` and a `task` saying how to go on: it hears what became of each
worker, and nothing restarts by itself.

Codex writes only inside the workspace; Claude's `Edit` and `Write` do too, but
its `Bash` and every Antigravity command can reach any file the user can. Check
`git status` after a cancel or timeout: partial changes stay. If the server ended
meanwhile, the task reads `interrupted`. A delegation through Codex marks the work
tree as trusted in the user's `~/.codex/config.toml`; Codex does this itself, and
the entry stays.