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.)
3. Settled — treat as ground truth — every locked decision WITH its one-line why, including rejected options and why rejected. Don't re-litigate these.
4. In progress / still open — what's unfinished or mid-flight right now.
5. 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.
6. Constraints & preferences — hard requirements; the user's tastes, tone, working style, quality bars, budget/time limits, things to avoid.
7. Open questions — unresolved threads, pending user decisions, unknowns.
8. Next step(s) — immediate next action(s), ordered, concrete enough to start without asking "so what now?".
9. 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.
10. 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 — <domain>:

• 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-<short-topic>-<YYYY-MM-DD>.md and share the download.
3. 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).