Relay

Relay — chat-to-chat context transfer

Pass the baton between Claude chats: capture full context here, paste it into a fresh chat, continue without missing a step.

Prime directive

Completeness beats brevity. A long, complete briefing that the next chat can act on beats a tidy one that dropped something load-bearing. Do NOT compress to look neat. Only omit what is genuinely redundant. When unsure whether a detail matters, keep it — the cost of an extra paragraph is trivial; the cost of a lost decision is the next chat redoing hours of work. This overrides any instinct to be concise.

What this does

Long chats degrade: context fills, tokens burn, answers get less sharp. This skill reads the entire current conversation and produces ONE self-contained briefing the user copies into a fresh chat. The new Claude reads it, verifies it, and continues exactly where this one left off.

Chat-native: no repo, git, filesystem, or Claude Code environment assumed. The primary deliverable is a paste-block printed in chat. When a file/canvas/code tool IS available, ALSO save the same content as a downloadable .md — and USE that access to do a better job (see Step 0).

Step 0 — Read the whole conversation FIRST (do not skip)

The single biggest failure mode is writing from memory/salience instead of the actual conversation — recent and vivid turns get captured, early ones silently vanish. Prevent this deliberately:

• If you can read files/transcripts (code tool, uploaded transcript, project

files): read them. Long sessions may live in a transcript file and/or a compaction summary at the top of context — read BOTH, oldest first. Read the actual referenced artifacts (specs, docs) rather than trusting your memory of them.

• Do a structured extraction PASS, not a recall. Walk the conversation in

chronological chunks (e.g. beginning → middle → recent). For EACH chunk, jot what it added: decisions, rejected options, files created, traps hit, user preferences, open threads. THEN assemble the briefing from those notes. This chunked pass is how early material survives — do it even for pure-chat sessions by mentally walking from the first message forward, not backward from the last.

• Coverage check: before writing, confirm you've accounted for the START of

the session, not just the end. If the session had distinct phases (e.g. research → design → naming → build), each phase should appear in the briefing.

Invocation

Explicit only (disable-model-invocation: true) — never fire automatically mid-task. It's fine to offer ("want me to relay this?") when a chat is clearly long, but only run it on the user's say-so. Rule of thumb: relay at ~50–75% context, before answers lose sharpness.

Purpose-tailoring (if the user gives a focus)

If the user says what the next chat is for ("relay — next chat is just the dev build"): lead with and expand the relevant domain block(s); keep other domains to a brief line each (don't delete — the next chat may still need to know they exist); sharpen "Next steps" to that purpose. If no focus given, capture the whole session evenly and completely.

The briefing — sections (in order)

Open with the RESUME PROMPT (verbatim, at the very top):

> You are a fresh Claude chat picking up work from a previous one. This is your > briefing — read all of it before doing anything. Treat every claim as context to > verify, not fact to trust blindly; if something can be checked, check it. Do not > redo anything under "Settled", and do not repeat approaches under "Traps". When > you've read it, briefly confirm you're oriented, restate the goal in one line, > and state the next step you'll take — then wait for my go-ahead unless I've told > you to proceed.

Then a one-line meta stamp: Relay #N · domains: … · [next-chat focus: …] · DATE.

Then the CORE (always). Be concrete — names, numbers, versions, exact wording of decisions. Never invent; write "None" if a section is truly empty.

1. Goal — what the user is ultimately trying to achieve (prose, 1–4 sentences).
2. How we got here — a short narrative of the session's arc / phases, so the

next chat understands the journey, not just the endpoint. This is where early context that isn't a discrete "decision" survives. (2–6 sentences.)

1. Settled — treat as ground truth — every locked decision WITH its one-line

why, including rejected options and why rejected. Don't re-litigate these.

1. In progress / still open — what's unfinished or mid-flight right now.
2. Traps / what didn't work — dead ends, failed approaches, mistakes already

made, things the next chat will be tempted to retry that were ruled out. Protect this section; it's the most expensive thing to rediscover.

1. Constraints & preferences — hard requirements; the user's tastes, tone,

working style, quality bars, budget/time limits, things to avoid.

1. Open questions — unresolved threads, pending user decisions, unknowns.
2. Next step(s) — immediate next action(s), ordered, concrete enough to start

without asking "so what now?".

1. File & artifact manifest — REQUIRED when the session produced or relied on

files/docs. For EACH key artifact, one row: name/path — what it is (1 line) — why it matters / what's in it — read this when. Prioritize (mark the 2–3 the next chat should read FIRST). This section is often the most valuable in the whole briefing — do not reduce it to a bare list of filenames.

1. Suggested skills for the next chat — e.g. "run relay again before this

chat gets long". Omit if none.

Then the DOMAIN block(s) (conditional — one per detected domain), under ## Domain notes — :

• coding/technical: stack & versions; architecture/data-flow; files/modules

touched; commands that work (build/test/run) and any that failed; bugs open vs fixed w/ root cause; test/verification state; env/config gotchas.

• design: design tokens (exact values); components/screens done vs pending;

design rationale/direction; assets & locations; contrast/responsive/a11y issues; what was explicitly rejected visually.

• writing/content: audience & voice; outline/structure; drafted vs outlined

vs unwritten; titles chosen; style rules; sources; publishing target & format.

• research/analysis: the question; sources (with what each showed); methods;

findings; contradictions/gaps; confidence levels; what still needs checking.

• marketing/growth: positioning & message; audience/ICP; channels; assets;

metrics/targets; test results; brand rules; the plan and where it stands.

• strategy/planning: decision(s) at stake; options with trade-offs; chosen

direction & why; risks/dependencies; timeline; stakeholders; committed vs open.

• generic: skip; the core already covers it.

Self-check before output (quality gate)

Silently verify and fix before printing:

• Coverage: the START of the session is represented, not just the end. Each

major phase appears. (If you can't point to where early material is captured, re-read and fix.)

• File manifest present & described (not bare filenames) when files exist.
• No hollow sections — real content or "None"; no vague filler.
• Secrets redacted — no keys/passwords/tokens/PII verbatim; use a placeholder.
• Next steps concrete; decisions carry their why; **artifacts referenced,

not re-embedded** (point to them; don't paste their full contents). Don't report the check to the user — just output a clean, complete briefing.

Output

1. Print the full briefing in chat as ONE fenced code block (one-tap copy).
2. If a file tool is available, also save relay--.md

and share the download.

1. End with: "Open a new chat and paste the block above as your first message."

Formatting

Prose for Goal and How we got here; tight bullets/rows for everything else (Settled, In progress, Traps, Constraints, Open questions, Next steps, manifest, domain items). Hybrid beats pure-prose (loses structure) and pure-bullets (fragments meaning). Complete first, then as short as completeness allows. Reference long artifacts; never re-embed them.

Chaining

If this conversation began from a pasted relay, note "Relay #N in this thread" at the top and carry forward still-relevant items so history survives 3+ hops.

Guardrails

• Completeness beats brevity (see prime directive) — but never pad with filler.
• Redact sensitive data — keys, passwords, tokens, PII → bracketed placeholder.
• Never fabricate. "None"/"Unknown" beats invented detail.
• Don't dump raw conversation; synthesize — but synthesize ALL of it.
• The paste-block is the product; the file is a bonus. Never skip the paste-block.
• This skill captures and formats — it can't open the new chat (a chat can't).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mosuvo
• Source: mosuvo/relay
• License: MIT
• Homepage: https://x.com/mosuvo

Install and usage instructions live in the source repository linked above.