peer-coordinate

# Peer Coordinate Skill Communicate with peer robots via RCAN to consult, delegate, or collaborate. ## Steps ### 1. Identify the target robot Map the robot name mentioned by the user to an RRN: - "Bob" → RRN-000000000001 - "Alex" → RRN-000000000005 - Unknown name: ask user to clarify or check with `get_telemetry()` for fleet list ### 2. Compose the message Frame a clear, concise message to the peer robot. Include: - What you need (question, task delegation, status check) - Relevant context (what the user asked, what you've already done) ### 3. Send via RCAN Call `send_rcan_message(rrn="RRN-XXXXXXXXXXXX", message="...")`. Timeout: 10 seconds. If no response: report timeout and offer alternatives. ### 4. Synthesise response Combine the peer's response with your own context and present a unified answer to the user. Attribute clearly: "Alex says: ..." ## Protocol 66 note This skill only sends `scope: chat` messages. Physical actions on the peer robot are governed by that robot's own P66 layer — you cannot override them. Do NOT attempt to command a peer robot to perform physical actions through chat. ## References See `references/fleet-roster.md` for current fleet members and their capabilities. ## Gotchas - **Peer offline** — `send_rcan_message` timeout doesn't mean the robot is broken; it may be busy, low-battery, or in a non-chat mode; always report "I couldn't reach Alex — she may be occupied" rather than "Alex is offline" - **Scope = chat only** — you can ASK a peer to do something, but the peer's own P66 layer controls whether it acts; never phrase a peer message as a command you expect to be auto-executed ("do X now") — ask instead ("would you be able to X?") - **RRN format** — must use full `RRN-000000000001` format; short names ("Bob") are NOT valid RRN values; always resolve before calling `send_rcan_message` - **Message length** — keep peer messages concise (< 300 chars); long context dumps are expensive and the peer's model may truncate them; summarise what you need - **Cascading delegation** — if you ask Alex to ask Bob, this creates a chain that can timeout; for three-robot coordination, the user should coordinate directly rather than daisy-chaining messages - **Gemini ADC on Alex** — Alex's brain uses Google OAuth; she may occasionally have slower cold-start responses on the first message of a session ## Example User: "Ask Alex what she sees" → `send_rcan_message("RRN-000000000005", "What do you currently see with your camera?")` → Alex responds: "I see a workbench with tools and a Lego set." → "Alex says she can see a workbench with tools and a Lego set." User: "Coordinate with Bob to sort the bricks — you handle red, Bob handles blue" → `send_rcan_message("RRN-000000000001", "Sorting task: please pick up all blue Lego bricks. I will handle the red ones.")` → Bob: "Understood, starting blue brick collection." → Report plan to user, then proceed with red brick task using arm-manipulate skill