relay

Relay — the primary chat of a pair-programming-by-worktree session

The human and this chat (the primary) share ONE working worktree + branch. The human edits files there and leaves comments — their reference of "what is being addressed". The primary turns comments into topics and drives each through a sub chat running the worktree skill on its own worktree. Work lands on <integration> only through that skill's gate, in the sub chat, approved by the human there. The shared branch is reference only: nothing on it ever reaches <integration> directly, and it is deleted when the relay ends.

<integration> / <protected> resolve exactly as in the worktree skill (GIT_GUARD_INTEGRATION_BRANCH / GIT_GUARD_PROTECTED_BRANCH, else probe and confirm). Everything here assumes the Claude desktop app's session tools (start_session, SendMessage, archive_session, set_session_model, set_session_effort, Monitor); without them, the primary can only prepare briefs for the human to paste.

Voice

Same as the worktree skill: silent execution, terse required beats. The required beats here are: the start report · a topic proposal / question · a spawn report (slug + session) · a land report (what landed, what was stripped, what is still in flight) · the close report. One status line for everything in flight — never a list of the sub chats' pending questions.

Start — the primary's gate

/relay loaded → this chat is the primary. Before anything else:

1. Prove the shared worktree: pwd under the worktrees dir (never the main checkout); git rev-parse --abbrev-ref HEAD = this worktree's own branch — any name the app gave it (typically feature/relay-<topic>-<hash>; the app names worktree branches, never rename it) — that is neither <integration> nor <protected>; cut off <integration> (fork-point compare as in the worktree skill). That branch is <relay-branch> below. Mismatch → HARD STOP, hand the human a restart prompt (new session, worktree ON, base <integration>).
2. Check the models: RELAY_PRIMARY_MODELS is the preference list for this chat, RELAY_SUB_MODELS for sub chats — both model@effort lists, first available wins (echo $RELAY_SUB_MODELS; defaults in § Settings). If this chat is not running the first entry it can, say so in one line; the human picks the model in the app. Run at the highest effort the list allows: a sub chat starts at or below the primary's own model/effort, and lifting it afterwards (§ Spawn) costs the human one confirmation per sub chat.
3. Write .agent/relay.md in the shared worktree (create or resume): the topic, <relay-branch>, <integration>, a ## Topics table — slug · session · branch · status · files (status: proposed / in flight / landed / done), and ## Watcher (state dir, armed-until). Commit it as the single evolving state commit (§ The shared branch) — it is never landed, it dies with the branch.
4. Check the landing wiring once: git worktree list — if <integration> is checked out in the main checkout, every sub chat's land is refused the moment that checkout is dirty, and the primary can do nothing about it but report. Say so in one line (the fix is the worktree skill's one-time _integration worktree); a sub chat blocked on a dirty <integration> checkout is a one-line report to the human, never a reason to touch that tree.
5. Keep the watcher's state out of git: append .agent/relay-watch/ to $(git rev-parse --git-common-dir)/info/exclude (never to a tracked .gitignore).
6. Take stock of what is already there: read git diff HEAD yourself, then relay-watch --seed <worktree> .agent/relay-watch so the watcher reports only what the human writes from now on — otherwise its first tick floods you with every pre-existing comment, your own notes included. Existing comments are the backlog: list them as topic candidates in one message (file · count · gist) and let the human pick; never one question per file.
7. Arm the watcher (§ Watcher) and report: path · branch · <integration> · models · "watching".