/agent-coordination

name: agent-coordination
scope: common
description: Find other agents, list participants in a conversation, send routed messages, attach files, and recover earlier conversation context (history / resolve a fuzzy reference / read a quoted message / read compressed summaries). Use whenever you need to delegate to another agent, address a peer in a multi-agent conversation, send a message that carries a file, or pull context that scrolled out of your prompt window. Executes via `cloud discover`, `cloud im conversations`, `cloud send`, `cloud file send`, `cloud conversation history|resolve-identifier|summary`, and `cloud quote read` CLIs.

Agent Coordination

Multi-agent workspaces route messages between named agents. This skill bundles the four-step flow: **discover → list-in-conversation → send → (optional) attach file**. The platform enforces that messages are routed to **agents who are participants in the conversation**, so you can't shortcut steps 1–2 even when you "know" the username from chat text.

⛔ Inline subagents are NOT delegation

If you have an inline `Task` / `Subagent` / `ParallelAgents` / fan-out tool available (Anthropic Claude Code, Cursor, Cline, etc.), **never use it to fulfil a "delegate to <peer-agent>" request**. Inline subagents:

• run in your own process, with your own context and credentials
• never appear on the workspace Kanban
• never @-mention the supposed assignee in the conversation
• finish in seconds, which to the user looks like you did the work yourself (because you did)

For peer-agent delegation, the canonical paths are **`cloud task create --assignee-name <peer>`** (tracked deliverable; see the `tasks` skill) and **`cloud send <peer-username> "<message>" --by-username --workspace-id "$PRISMER_WORKSPACE_ID"`** (ad-hoc message; see below). Anything else — including inline subagents — is the wrong tool, and the user will notice (the supposed assignee was never @-mentioned in chat, and your response came back too fast).

`cloud task create` vs `cloud send` — 选哪条 + 结果回流

| 你想要的 | 用 | 结果怎么回来 | | --- | --- | --- | | **可追踪委派**（要交付物、要进度、要落看板） | `cloud task create --assignee-name <peer>` | **不自动回流**：peer 在独立 context 跑，产物落 task 卡；你须 `cloud task get <taskId>` 主动拉（`status=completed` 才算成）。详见 `tasks` skill 的「结果回流」段。 | | **即兴消息**（问一句、转一份、打个招呼） | `cloud send <peer-username> "<message>" --by-username --workspace-id "$PRISMER_WORKSPACE_ID"` | peer 若在**同一会话**，回复直接出现在这条会话里；不落看板、不可追踪。 |

口诀：**要结果 / 要看板 → `cloud task create` 然后 `cloud task get` 取**；只是说句话 → `cloud send`。两者都不是 inline subagent。

When to use

• The user asks to **delegate** something to another agent ("ask Bob to review this") — `cloud task create` for tracked work, `cloud send` for ad-hoc routing. **Never an inline subagent.**
• You're in a multi-agent conversation and want to **address** a specific peer.
• You need to **find an agent** with a specific capability (`code-review`, `data-analysis`, `repair`).
• You need to **send a message** that carries an attached file (report, log, image).

CLI Reference

Discover (workspace-wide directory)

cloud discover --workspace-id "$PRISMER_WORKSPACE_ID"                                  # all agents in this workspace
cloud discover --workspace-id "$PRISMER_WORKSPACE_ID" --capability code-review         # filter by capability
cloud discover --workspace-id "$PRISMER_WORKSPACE_ID" --online-only                    # only online agents
cloud im contacts                                 # users you've chatted with (conversation-derived)
cloud im contacts --external --workspace-id "$PRISMER_WORKSPACE_ID"  # your cross-workspace contact edges

`cloud discover` is a workspace-scoped Agent Registry contract: every result is backed by an AgentCard in the requested workspace and carries its routing `userId`. Agents from other workspaces are NOT in this directory — the only legitimate cross-workspace targets are your **external contact edges** (`cloud im contacts --external`, built by the owner's 「添加外部联系人」+ 双侧 approval): each entry carries the peer's `imUserId` (use it as the send target), its workspace name, and its lifecycle. If the user asks you to reach an agent outside this workspace, check that list first — if the peer is there, message it directly; if not, say plainly that no external contact edge exists and the owner must add the contact first. When the target is already in the current conversation, prefer the conversation members listing below instead of searching.

List participants in a conversation (scoped)

cloud im conversations                            # all your conversations
cloud im conversations --unread                   # unread only
cloud im conversations <conversationId> --members --json # exact agent + human participant fields

Send a message

# Direct message to an agent
cloud send <to-username> "Please review the PR" --by-username --workspace-id "$PRISMER_WORKSPACE_ID"
cloud send <to-username> "## Report" -t markdown --by-username --workspace-id "$PRISMER_WORKSPACE_ID"
cloud send <to-username> "Acknowledged" --reply-to <messageId> --by-username --workspace-id "$PRISMER_WORKSPACE_ID"

# Conversation-scoped (multi-agent group)
cloud im groups send <groupId> "Team update: feature shipped"

# With routing metadata
cloud send <to-username> "Need approval" --conversation-id <convId> --by-username --workspace-id "$PRISMER_WORKSPACE_ID"

# Cross-workspace external contact (must appear in `cloud im contacts --external`)
cloud im send <peer-imUserId> "hello across workspaces"

**Deferred (202 ACTION_DEFERRED):** a cross-workspace send without an active contact edge does NOT deliver — it returns `deferred` with an `approvalId` and the message waits for contact approval (both-side owner approval). Report that plainly to the user: "已发起联系人请求，等待对方台审批（approvalId: …）； 批准后重新发送。" Never report such a send as sent.

Send with attached file

> **决定怎么交付文件 — 先读这条:** > > - **用户明确要求随当前回复交付的文件** → 写入 > `${