Coding Agent (delegation)

When the work is "implement this feature, here are the files," delegate to a specialized coding CLI. This skill runs the chosen CLI inside the process tool so the user has full audit + kill control, and records the delegation under the workspace's .ethos-work/delegations/<id>/ for replay.

When to use this skill

• The user explicitly named a CLI: "have Claude Code do this", "delegate to codex".
• The coordinator pattern is active and the work is large, file-heavy, or requires sustained editing across many files.
• The work is "implement this feature with these constraints" rather than "decide what to build" — delegation is for execution, not planning.

When the change is small (one file, a few lines), do not delegate — execute it directly.

Step 1 — pick the right CLI

If the user did not specify, ask. Do not silently pick one.

Step 2 — verify the chosen CLI is installed and authenticated

Run the adapter's check commands before spawning. Each adapter file documents:

• The which <cli> test (or platform equivalent).
• The version check.
• The auth status check.
• The error to print if any of those fail (with the exact install + login command for the user to run).

Refuse to delegate if the CLI is not installed or not authenticated. A graceful refusal beats spawning a process that fails opaquely.

Step 3 — spawn via the process tool

process_start({
  command: "<cli> <args>",
  name: "delegated-<id>",
  cwd: <project-root>,
})

Capture the returned process_id. The id part of the name is a short slug derived from the request (e.g. delegated-rate-limit-2026-05-06-1430).

Pass any context the delegated CLI needs through its own argument or stdin convention — see the adapter files.

Step 4 — watch logs

Use process_logs to surface progress to the user. Two patterns:

• Tight feedback (small delegations): poll logs every 10-30 seconds, summarize what the CLI is doing.
• Long delegations: tell the user "delegated; I'll surface progress when there's a meaningful update", then check logs only when explicitly asked or when process_wait indicates completion.

Never silently let a delegated process run forever. Set a time-box up front and check it.

Step 5 — handle completion

When the delegated CLI exits:

1. Capture exit code, total runtime, and the final log lines.
2. Record the session under .ethos-work/delegations/<slug>/ in the project root (add .ethos-work/ to .git/info/exclude; not ~/.ethos, which the terminal guard refuses):

   <slug>/
   ├── command.txt          # the exact command spawned
   ├── stdout.log           # full stdout
   ├── stderr.log           # full stderr
   ├── files-touched.txt    # list of files the delegated CLI modified
   └── result.md            # summary, exit code, recommendation

3. Summarize the result back to the user: success / partial / failure, what changed, whether to merge or roll back.

Step 6 — clean up

If the user is done with the delegation, the session record stays for replay but the running process is gone (it already exited). If the user interrupted mid-flight, kill the process with process_stop before exiting the skill.

Hard rules

• Never spawn a delegated CLI without the process tool. Without it, the chat blocks for the full delegation duration and the user can't kill it. Refuse delegation and surface the prerequisite gap.
• Never delegate work the user has not authorized. Coordinator personalities should ask before delegating, not after.
• Always record the session. A delegation that is not auditable is a delegation that cannot be debugged.