cross-window

name	cross-window
description	Hand a task to another agent window via send_to_window.
scope	agent

Use send_to_window when a slice of the user's task fits another open profile's scope better than yours. Profiles: vela (general), coder (github + linear), scribe (notion + gmail), comms (slack + gmail + calendar). Only one window per profile can be open at a time, so addressing by profile is unambiguous.

Deliver, don't enrich. When the user's instruction is shaped like "tell X to do Y" or "ask X to handle Y", the deliverable is the telling. Y does not need to be enriched, validated, or completed by you before handoff — the recipient will do that. Compose a self-contained message with what you have, including the user's words verbatim if they said it concisely, and call send_to_window once.

If you don't have enough context for the recipient to act, ask the user — don't spend a tool budget gathering it yourself. The user is faster than 10 tool calls.

When to use:

• You're Coder and you've drafted a Slack post — hand it to comms instead of asking the user to copy/paste.
• You're Comms and the user wants a code summary — hand the request to coder, then take its output and post it.
• You're Scribe and the user wants a PR review filed as a Notion page — first send to coder to gather PR context, then write up the result yourself.

When NOT to use:

• The recipient profile isn't open. The tool will return "No ${profile} window is open. Ask the user to open one." Do that — don't try to spawn one yourself.
• You have the tools to do it yourself. Don't bounce work to another window for the sake of theatre.
• You'd be the third+ hop in a chain. The tool enforces a 3-hop limit; if you hit it, stop and reply to the user directly.

Writing the message:

• Self-contained. The recipient will not see this conversation. State the goal, the constraints, and the deliverable.
• One ask per call. If the recipient needs to do two things, send two messages (or, better, ask once and let them break it down).
• Keep it short. ~2-5 sentences is right. The recipient is an agent, not a copilot — they don't need bedside manner.

What to expect:

• The tool returns "Queued for ${profile}. The user will be asked for permission to deliver." — that means the request left this window. The user has to approve before the recipient sees it.
• The user will see a permission dialog on this window with Accept / Always-accept / Decline buttons. They control whether the message actually flows.
• You won't receive the recipient's reply automatically. The user can either tell you what came back, or you'll see it from your reading of the canvas.

When the tool errors:

• "No ${profile} window is open" — explain the situation to the user and ask them to spawn one. Don't retry the call.
• "Hop limit exceeded" — break the chain. Reply to the user directly with what you have.
• "Cannot send to the same window" — wrong profile target; pick a different one.

One line to the user when you call it: name the recipient and the slice you're handing off. ("Asking Comms to post this to #eng-updates.")