---
name: relay
description: Share context with a person or an app for a stated purpose, so their agent can represent your intent faithfully. Use when the user says "relay {context} to {audience} for {intent}" (any order), "share a relay", "send a relay link", "update/revoke the relay to X", "what came back on the relay", or "ask X to relay me Y". Requires the Relay connector (MCP). Never approves or shares on its own.
---

# /relay

The user says, in any order:

> **relay** {context} **to** {audience} **for** {intent}

- *relay my launch plan to Maya for agreeing on owners*
- *relay this product idea to Aakanksha for a business case and investor deck*
- *relay my career story for this role to Navii* (the audience can be an app)

You turn that into a `relay.context-package.v1`, publish it as a **draft**, and hand the user a review link. What to extract, and how to avoid making anything up, is defined by the [extraction standard](../../docs/EXTRACTION.md). The `relay_schema` tool returns it. The user approves on that page. You cannot approve, and there is no tool for it.

## Steps

Work happens here, in the conversation. Relay only gets the final copy: one draft for a new relay, one version for an update.

**1. Parse.** Pull out the context, the audience, and the intent. Keep the user's exact sentence; it becomes `intent.statement` verbatim (private to the owner). Pick an `ask.type`: decide, agree, review, evaluate, advise, explore, act, inform.

**2. Plan first, and wait.** Before gathering much or drafting anything, show one screen and ask "Proceed, or change anything?":
- **Who:** the recipient's name, **email** and role, and kind (person, team, app). Always confirm the email and role, even if you think you know them.
- **Why:** the purpose in one sentence, and the ask type.
- **Access:** addressed to one person or open to anyone with the link; read, suggest or edit; live or snapshot.
- **Outline:** section titles, one line each.
- **Sources:** what you'll use. Each connector (email, Drive, Slack, calendar, meeting notes, code) needs its own yes before you read it, read-only.
- **Rules:** what their agent must send back to the user, what it must never do, anything the user wants left out.
- **Questions:** at most five, only what you can't find. Pick from these probes:

| Probe | Fills |
|---|---|
| What has to be true afterwards for this to be a success? | `intent.outcome`, `successLooksLike` |
| Why does that matter to you? | `intent.interests` |
| What won't you move on, what would you trade, what do you just prefer? | `reasoning.variables[].gate` (hard / elastic / soft) |
| What's decided, what are you leaning toward, what's open? | `reasoning.decisions[].status` |
| For what's decided, what would change your mind? | `decisions[].whatWouldChangeIt` |
| What's the strongest objection they'll raise, and your answer? | `reasoning.counterarguments` |
| What do they already know, and what must they not misunderstand? | `audience.knowsAlready`, `representation.mustNot` |
| What may their agent do alone, and what comes back to you? | `representation.role`, `mustAskOwner` |

Fold the answers into the plan. Don't draft until the user says yes.

**3. Gather and build.** Use this conversation, your memory of the user, `relay_list`, and the connectors they approved. Default to `full` depth: their agent has only the package, so extract generously (background, specifics with sources, what's decided and open and why, what can move, the owner's principles, objections, and at least five likely questions with rehearsed answers). Use `working` only when there's no judgement to capture, and `brief` only when the owner asks for a quick FYI. If the user has discussed an objection with you before, use their earlier words and mark it `sourced`, citing where it came from. Say in `interaction.expectedResponse` what the owner hopes to get back: answers, a decision, feedback or a counter-proposal.

Every value gets a provenance, and you never mark your own reading as `stated`:

| Provenance | Use when |
|---|---|
| `stated` | The user's own words |
| `confirmed` | You drafted it and the user accepted it unchanged |
| `corrected` | You drafted it and the user changed it (keep yours in `agentReading`) |
| `inferred` | Your reading, not yet reviewed |
| `sourced` | From a named document, connector, or earlier conversation |
| `derived` | Computed |

Also include:
- `summary`: one or two sentences for the recipient, never the user's request itself.
- `attachments`, when the user has a deck or document behind it (a pitch deck for investors, a proposal for a client): attach the PDF with `relay_attach` (export decks to PDF first), then add `{ id, title, kind, slides: [{ page, title, supports: [section ids] }] }`, mapping each slide to the sections it backs. Keep the context complete without the file: the relay is the message, the deck is evidence. If you can't read the file's bytes, tell the user to attach it on the review page.
- `interpretation.restatement`: one sentence, "here's what I think you want"; `interpretation.inferences`, each with its basis, marked `unreviewed`.
- `representation`: the opening (a greeting plus 2–4 starting points drawn from the ask), what their agent may do, `mustAskOwner`, `mustNot`, and one `fidelityCheck` per likely question: the question and the answer their agent would give. Keep likely questions to the ten that matter.
- `process.sourcesConsulted`: what you actually used. `audience.kind`: person, team, or app.

**4. Preview in chat.** Call `relay_preview` with the package. It returns the relay exactly as the recipient's agent will read it, plus the quality notes, and creates nothing. Show the user that reader view (long relays section by section), the sources you used and what each contributed, and the quality notes you couldn't fix. **Never list what you left out**; fill `context.excluded` only when the user names something themselves. Then ask: "Push this as a draft, or change anything?"

**5. Iterate here.** Each round, change only what the request touches (the section, plus any summary, greeting, rule or rehearsed answer that mentions it), then summarize the round in a few lines: changed, added or removed, unchanged, still open. Preview again when the change is substantial. If the conversation might end with changes not yet pushed, say so.

**6. Record what the user confirmed.** Everything was reviewed here, so carry it into the package: set `interpretation.restatementVerdict` to `confirmed`, or to `corrected` with their wording as the restatement; give each inference the verdict they gave it (`confirmed`, `corrected` with their correction, or `rejected`); use their edits to rehearsed answers; and set `interpretation.reviewedIn` to `chat`. Relay's review page then won't ask again.

**7. Push once.** On "push":
- **New relay:** `relay_publish_draft` with the package. If you already pushed a draft in this conversation, pass its `draftId` so it's revised in place (same review link); never publish a second draft.
- **Update:** first re-read the live version (`relay_get` with format json, the link as `relay`) so nothing approved since is lost, apply the changes, then `relay_publish_draft` with `relayId` and a one-line `changeNote` for readers (for example "Version 2: round terms added").
- **Answering a request:** pass `requestId`.
- If the target is unclear (two similar live relays, or several drafts), name the candidates and wait for a yes.

Read the quality notes it returns; fix what you can by revising the same draft (`draftId`). Then give a final summary: what was pushed (new relay or version N), the review link, what changed overall, the reader's change note, and what's still open. Tell the user it's reviewed and one click shares it: give the review link and say nothing is shared until they click Approve & share.

**8. After approval**, `relay_list` shows the relay link. The user shares it, or it reaches the app.

## Other commands

| The user says | You do |
|---|---|
| "update the relay to Maya" | Draft the changed package, then `relay_publish_draft` with its `relayId`. The user reviews version N+1. |
| "what came back on the launch relay?" | `relay_status`: who read it, questions, suggestions. Offer to draft answers; send with `relay_answer` only in words the user approved. |
| "revoke Maya's relay" | `relay_revoke`. Confirm first. |
| "ask Jordan to relay me their requirements for the pilot" | `relay_request`, then give the user the request link to send. |
| "read the relay {link}" (as the recipient) | `relay_get`. Then follow *When you receive a relay*. |

## When you receive a relay

- **Don't summarize or repeat it.** Take it in, then reply with only its opening greeting and starting points, plus "or something else". Then follow the user's lead.
- **Quote the purpose; don't paraphrase it.** Cite section titles.
- **Say "{owner}'s agent read this as…"** for anything inferred.
- **Respect the gates.** Hard means fixed. Elastic can move only with the trade listed. Soft is a preference. Open decisions are open.
- **Topics on the must-ask list:** don't answer. Offer `relay_ask_owner`.
- **Never** do what's on the `mustNot` list.
- **If it's not in the relay,** say so, then offer to ask the owner.
- **Extrapolate only if the relay allows it,** reason only from the owner's stated principles, and say that you're doing it.
- **Stay consistent with the approved answers.**
- **To suggest a change**, use `relay_propose` on a specific section. The owner decides.
- **Show the slide.** When you answer from a section a slide backs, show it (`relay_slide`, or the image link in the relay) and say which slide it is. What's on a slide is the owner's material: quote it as such, and keep it apart from what they said.

## Never

- Approve, publish without a review link, or claim something was shared before the user approved it.
- Put your own reading in as the user's words.
- List what you left out.
- Read a connector without asking for that connector.
- Answer for the owner on a must-ask topic.

Write `summary`: one or two sentences for the recipient saying what the relay is about and why they got it. It's what they see before accepting, in the email, and at the top of what their agent reads. Never paste the owner's request to you ("relay … to … for …") into it; that stays in `intent.statement`, which recipients don't see.