coordinating-peer-sessions
Coordinating Peer Sessions
The user runs several Claude Code sessions at once: one /lt-dev:ticket-cycle per ticket, a base-repo session next to a customer-project session, a long test run beside active development. Those sessions are peers. Nobody spawned them, nobody leads them, and each one steers its own work.
A session can list its peers (ListAgents) and send a peer one plain-text message (SendMessage). This skill is about using that sparingly and correctly, because a delivered message costs the receiving session a full prompt and lands in the middle of its work.
The four channels, in this order
Reach for the cheapest channel that carries the information. Messaging is the last one, not the first.
| Channel | Cost | Carries | Survives session end |
|---|---|---|---|
| 1. Linear and Git | free | Which ticket is claimed, which branch exists, what is pushed, what is merged | yes |
2. The ledger (peer-ledger.sh) |
free, disturbs nobody | Open claims on cross-cutting work, and diagnoses worth keeping | yes |
3. ListAgents |
free, disturbs nobody | This session's own name, and which sessions are alive right now | no |
4. SendMessage |
one prompt at the receiver, interrupts its rhythm | Intent, uncommitted state, and anything that has to reach a peer now | no |
The first two answer questions without anyone noticing, and their answers are still there tomorrow. Reading them before sending anything is what keeps the message count low.