prompt.ts
tools/SendMessageTool/prompt.ts
50
Lines
2356
Bytes
2
Exports
1
Imports
10
Keywords
What this is
This page documents one file from the repository and includes its full source so you can read it without leaving the docs site.
Beginner explanation
This file is part of the tool layer, which means it describes actions the system can perform for the user or model.
How it is used
Start from the exports list and related files. Those are the easiest clues for where this file fits into the system.
Expert explanation
Architecturally, this file intersects with tool-system. It contains 50 lines, 1 detected imports, and 2 detected exports.
Important relationships
- tools/SendMessageTool/SendMessageTool.ts
- tools/SendMessageTool/UI.tsx
- tools/SendMessageTool/constants.ts
- buddy/prompt.ts
- services/compact/prompt.ts
- tools/AgentTool/prompt.ts
- tools/AskUserQuestionTool/prompt.ts
- tools/BashTool/prompt.ts
- tools/BriefTool/prompt.ts
- tools/ConfigTool/prompt.ts
- tools/EnterPlanModeTool/prompt.ts
- tools/EnterWorktreeTool/prompt.ts
Detected exports
DESCRIPTIONgetPrompt
Keywords
messagejsonyourfeaturesendlistpeersmessagesresearcherteammatesrequest_id
Detected imports
bun:bundle
Source notes
This page embeds the full file contents. Small or leaf files are still indexed honestly instead of being over-explained.
Full source
import { feature } from 'bun:bundle'
export const DESCRIPTION = 'Send a message to another agent'
export function getPrompt(): string {
const udsRow = feature('UDS_INBOX')
? `\n| \`"uds:/path/to.sock"\` | Local Claude session's socket (same machine; use \`ListPeers\`) |
| \`"bridge:session_..."\` | Remote Control peer session (cross-machine; use \`ListPeers\`) |`
: ''
const udsSection = feature('UDS_INBOX')
? `\n\n## Cross-session
Use \`ListPeers\` to discover targets, then:
\`\`\`json
{"to": "uds:/tmp/cc-socks/1234.sock", "message": "check if tests pass over there"}
{"to": "bridge:session_01AbCd...", "message": "what branch are you on?"}
\`\`\`
A listed peer is alive and will process your message — no "busy" state; messages enqueue and drain at the receiver's next tool round. Your message arrives wrapped as \`<cross-session-message from="...">\`. **To reply to an incoming message, copy its \`from\` attribute as your \`to\`.**`
: ''
return `
# SendMessage
Send a message to another agent.
\`\`\`json
{"to": "researcher", "summary": "assign task 1", "message": "start on task #1"}
\`\`\`
| \`to\` | |
|---|---|
| \`"researcher"\` | Teammate by name |
| \`"*"\` | Broadcast to all teammates — expensive (linear in team size), use only when everyone genuinely needs it |${udsRow}
Your plain text output is NOT visible to other agents — to communicate, you MUST call this tool. Messages from teammates are delivered automatically; you don't check an inbox. Refer to teammates by name, never by UUID. When relaying, don't quote the original — it's already rendered to the user.${udsSection}
## Protocol responses (legacy)
If you receive a JSON message with \`type: "shutdown_request"\` or \`type: "plan_approval_request"\`, respond with the matching \`_response\` type — echo the \`request_id\`, set \`approve\` true/false:
\`\`\`json
{"to": "team-lead", "message": {"type": "shutdown_response", "request_id": "...", "approve": true}}
{"to": "researcher", "message": {"type": "plan_approval_response", "request_id": "...", "approve": false, "feedback": "add error handling"}}
\`\`\`
Approving shutdown terminates your process. Rejecting plan sends the teammate back to revise. Don't originate \`shutdown_request\` unless asked. Don't send structured JSON status messages — use TaskUpdate.
`.trim()
}