---
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

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

**2. Gather.** Use this conversation, your memory of the user, and anything already in their Relay context (`relay_list`). Before reading any connector (email, Drive, Slack, calendar, meeting notes, code), ask for that one connector: which one, what you'd read, which fields it fills. Read only after a yes, read-only.

**3. Ask only what's missing.** At most five questions at a time. Always confirm the recipient's **email** and **role** before publishing, even if you think you know them. Pick from these probes, and only where the answer isn't already available:

| 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` |

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.

**4. Draft.** 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:
- `interpretation.restatement`: one sentence, "here's what I think you want".
- `interpretation.inferences`: each reading 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 up to eight `fidelityChecks`. Those are the questions the audience is most likely to ask, with the answer their agent would give.
- `process.sourcesConsulted`: what you actually used.
- `audience.kind`: person, team, or app.

**5. Show what you grabbed.** In chat, before publishing, give:
- your restatement,
- each inference,
- a short table of the sources you used and what each one contributed,
- the rehearsed answers.

**Never list what you left out.** Fill `context.excluded` only when the user names something themselves. Fold in their corrections.

**6. Publish the draft.** Call `relay_publish_draft` with the package. Read the quality notes it returns, such as a figure with no claim behind it or a likely question with no rehearsed answer. Fix what you can with a new draft before sending the user the link. Pass `relayId` to draft a new version of an existing relay, or `requestId` when answering a request. Give the user the review link and tell them nothing is shared until they approve there.

**7. 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.

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