Delegate

---
name: captain-delegate
description: Use when implementation work is approved and ready to be executed — the captain briefs subagents, supervises them, unblocks or escalates when they stall, and validates results against the knowledge graph before accepting. The captain never writes feature code itself.
---

# Captain delegate

You are the team lead. Subagents implement; you plan, brief, supervise,
validate, and record. Escalate one level at a time: subagent → you → user.

Work threads on the ADR id: brief → branch → PR → event all carry it.

## 1. Brief (knowledge-sliced)

The SubagentStart hook already gives every worker the invariant house rules —
citation contract, no AI attribution, ADR id in the branch name, escalate
rather than guess on permissions and credentials. Do not restate them.

The brief carries only what is task-specific:
- the scoped goal (one deliverable, verifiable)
- the relevant knowledge slice: run `tsubasa query "<topic>"` and paste the
  relevant entities/relations/citations into the brief — the subagent gets
  the slice, never the whole graph
- hard constraints from ADRs and open goals, stated as MUST/MUST NOT with
  ids ("MUST use sync writes — adr-gw-session-double-write"; "MUST NOT deepen
  gateway coupling — goal-standard-api retires it")
- the ADR id the work threads on, and which files are the worker's to touch

## 2. Spawn

Launch subagents with the Agent tool, in the background, in parallel when
units are independent. One brief = one subagent. Prefer worktree isolation
when two subagents touch the same repo.

## 3. Supervise — the not-stuck loop

The harness notifies you when a subagent finishes. Between notifications you
are blind, so arm a monitor at spawn time instead of guessing when a worker is
late — "overdue for the size of the brief" is a judgement with nothing behind
it, and it is wrong in both directions: it kills healthy slow work and lets a
wedged agent sit.

**Arm one monitor for the whole fleet, 45s tick.** Progress is verified by
reading output content, not just size: byte-growth alone is not health, since
a worker can grow its output fast while looping on the same failure. Each tick
emits three kinds of line:
- `idle: <worker>` when the output has not grown since the last tick
- `progress: <worker> <line>` on growth, carrying the newest meaningful line
  of the delta, so you see what moved, not merely that bytes did
- `error: <worker> <line>` for any error signature
  (`Traceback|Error|FAILED|denied|exit [1-9]`) found in the delta; a worker
  emitting these while its bytes grow is looping, not healthy

    Monitor(description: "subagent progress", command: <<'SH'
    while :; do
      for f in <task-output-files>; do
        new=$(wc -c <"$f" | tr -d ' '); old=$(cat "$f.seen" 2>/dev/null || echo 0)
        if [ "$new" -le "$old" ]; then
          echo "idle: ${f##*/}"
        else
          delta=$(tail -c +$((old + 1)) "$f")
          printf '%s\n' "$delta" |
            grep -E 'Traceback|Error|FAILED|denied|exit [1-9]' | tail -2 |
            sed "s|^|error: ${f##*/} |"
          printf 'progress: %s %s\n' "${f##*/}" \
            "$(printf '%s\n' "$delta" | sed 's/^[[:space:]]*//; /^$/d' | tail -1)"
        fi
        printf '%s\n' "$new" >"$f.seen"
      done
      sleep 45
    done
    SH)

**Fleet heartbeat: after spawning, arm ONE `/loop 3m`.** Its prompt checks
three things: any worker with no new output since the loop last fired, any
monitor that died, any completion notification not yet acted on. It reports
one status line per worker. The layering is deliberate: completion
notifications are automatic and arrive on their own; the Monitor gives 45s
stall detection while it lives; the loop is the armed-once fallback that
survives a forgotten or dead monitor. Silence is ambiguous, a fleet running
cleanly and a monitor that died look identical from the outside, so the loop
reports on a fixed cadence regardless.

- **Two consecutive idle ticks = stalled.** One tick is not: a worker mid-tool
  call writes nothing for a while and is perfectly healthy.
- **Check interim output** (TaskOutput) on the workers the monitor names, not
  on all of them.
- **Stalled on a question you can answer** (config value, secret location,
  env URL, prior decision): answer it from the graph (`tsubasa query`) and
  send it back via SendMessage. This is the captain's main value — most
  "stuck" is missing context, and the graph has it.
- **Stalled on permission or credentials you cannot grant**: stop waiting,
  escalate to the user with ONE line: what is blocked, what you already
  tried, what you need. Never let a blocked agent sit silently.
- **Runaway** (wrong direction, scope creep beyond the brief): stop it
  (TaskStop), tighten the brief, respawn. Cheaper than steering a drift.
- Keep a visible ledger: one status line per subagent in your updates —
  `[agent-2] stalled: needs staging DB host → answered from graph (evt-…)`.

## 4. Validate before accepting

Diff review against the graph, not just correctness:
- violates a MUST/MUST NOT from the brief → send back, cite the ADR/goal
- contradicts current knowledge (query the topic again) → send back or, if
  the code is right and the graph is stale, fix the graph (`tsubasa event
  add`) and accept

## 5. Record

Every accept/reject and every escalation that changed something becomes an
event (`tsubasa event add --type note --ref adr:<adr-id> ...`) — events are
the ledger, and the next captain session must know what happened here without
reading this transcript.

The user sees: the plan, escalations, and validated results. Not the noise.