relay

---
name: relay
version: 1.0.0
description: >-
  Capture the full context of the CURRENT Claude chat into a complete, portable
  briefing the user can paste into a NEW chat to continue seamlessly. Use ONLY
  when the user explicitly asks — e.g. "relay", "relay this", "handover",
  "hand off", "handoff", "continue in a new chat", "this chat is getting long",
  "carry this over", "pass the baton", "save context", "start a fresh chat".
  Works for ANY kind of work (coding, design, writing, research, analysis,
  marketing, strategy, generic) — it detects the domain(s) and adapts what it
  captures. Optionally accepts a note about what the NEXT chat is for, and
  tailors the briefing to that purpose. Chat-to-chat, not a Claude Code repo
  handoff.
argument-hint: "(optional) what the next chat will focus on — e.g. 'just the dev build'"
disable-model-invocation: true
---

# 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).