Relay

Relay

Pass the baton to the next Sutando session. Where session-handoff.sh writes structured facts (recent commits, open PRs, pending Qs), /relay writes the narrative continuity — what you were just working on, what should be checked first, what might break and how to detect it.

Usage: /relay (writes a new relay file) or /relay --append (appends to the most recent unprocessed relay file rather than creating a new one).

Why this exists

src/session-handoff.sh pulls together the structured state for the next session — system status, recent commits, open PRs, pending questions, tasks, conversation tail, quota, repo stats — and writes it to session-state.md. But "I was about to land PR #X and Mini's review said Y matters most" isn't captured by git log, gh pr list, or pending-questions.md tail. The next session reads structured facts but has to RE-INFER the continuity, which costs context and frequently misses the load-bearing decision.

The relay note encodes intent + judgment — the thing only the LLM that lived through the session can write.

Folder layout

Mirrors Sutando's existing tasks/ and results/ convention:

workspace/relay/
├── relay-{epoch_seconds}.md     # pending relay notes (drained into session-state.md, then archived)
└── processed/
    └── relay-{epoch_seconds}.md # already drained; kept for audit

• File naming: relay-{epoch}.md — sortable + greppable, matches the task-{epoch}.txt shape.
• Multiple files allowed: /relay always creates a NEW file by default. --append appends to the LATEST unprocessed relay-*.md instead of creating a new one.
• Consumption: src/session-handoff.sh reads ALL unprocessed relay-*.md files in sorted order, appends them to session-state.md under ## Relay Notes (from prior sessions), then mvs each one to processed/ — but only after confirming its ### <basename> header landed in the written file, so an interrupt cannot retire an uncaptured note.
• Cleanup: kept indefinitely on local disk. Tiny files (~200-500 bytes each); a year of relay notes is < 1 MB. Sync via the workspace-sync engine (scripts/sync-workspace.sh) for fleet visibility — the legacy sync-memory.sh flow is deprecated in v0.3.0 and removed in v0.4.0.

What to write

Write a narrative note (~150–300 words typical, no fixed schema) covering:

1. What I was just working on — the active PR / thread / decision in flight. Be specific. ("PR #1429 just merged; was about to start the relay skill PR.")
2. What to check FIRST in the next session — concrete first action. ("Pull origin; verify the relay skill SKILL.md lints clean; ping owner on quality-gate decision.")
3. What might go wrong + recovery — known failure modes + how to detect them. ("If session-state.md has no ## Relay Notes section, the relay/ dir is probably orphaned; check ls workspace/relay/.")
4. Implicit context — the why-behind-the-what, decisions that haven't been committed yet, things you'd want a colleague to know if they walked in cold.

Don't write things that are already in the structured snapshot (recent commits, open PRs, pending-questions tail). session-state.md already carries those. Relay's value is the things the structured snapshot can't reach.

Steps