Skill: clawdpi-ai/openclaw-peer-bridge (version 1.0.0)

--- name: openclaw-peer-bridge description: Design and operate communication patterns between two OpenClaw instances. Use when a user wants one OpenClaw deployment to send status, tasks, reminders, audit results, or webhook callbacks to another OpenClaw deployment, or when defining a bridge between local and remote OpenClaw agents, dashboards, or automation flows. --- # OpenClaw Peer Bridge Design communication between two OpenClaw instances using supported primitives only. Prefer explicit, auditable flows: webhook delivery, cron delivery, channel routing, or user-mediated relay. Do not invent peer-to-peer commands or claim native cross-instance session sharing unless it exists in the current deployment. ## Core patterns ### 1. Event push via webhook Use when one OpenClaw instance needs to notify another system or service immediately. Pattern: 1. Source OpenClaw runs an isolated cron or task. 2. Delivery mode is `webhook`. 3. Target side exposes an HTTP endpoint that accepts the event and decides what to do next. Use for: - health checks - deployment notifications - audit summaries - workflow completion callbacks ## 2. Human-routed messaging bridge Use when the only guaranteed common surface between two instances is a chat channel. Pattern: 1. Instance A sends a structured message to a human-controlled channel. 2. Human or downstream automation forwards or triggers Instance B. 3. Keep payloads short, explicit, and idempotent. Use for: - approvals - escalation paths - low-frequency handoffs - cross-org workflows where direct network trust is not available ## 3. Scheduled relay Use when exact timing matters more than low latency. Pattern: 1. Source instance schedules a cron job. 2. Cron produces either an announcement or webhook. 3. Target instance or receiving system processes the scheduled event. Use for: - daily summaries - recurring audits - scheduled sync checks - heartbeat-style supervision ## 4. Local-to-remote control pattern Use when a workstation OpenClaw needs to coordinate with a server-side OpenClaw. Recommended split: - local instance handles human interaction, approvals, and dashboards - remote instance handles long-running jobs, server inspection, and isolated automation Design rules: - keep credentials local to the instance that needs them - push summaries, not raw secrets - define ownership of each task clearly - prefer append-only logs and explicit acknowledgements ## Workflow ### Step 1: define the bridge objective State the business outcome first: - alerting - task dispatch - result return - approval request - periodic reporting ### Step 2: choose the transport Choose the smallest sufficient transport: - webhook for machine-to-machine notifications - chat delivery for human-visible handoffs - cron for scheduled communication - local files only for same-machine coordination ### Step 3: define message contract Specify: - event name - sender instance - intended receiver - timestamp - payload fields - retry behavior - idempotency key if duplicate delivery is possible Prefer JSON for machine processing and short bullet summaries for human review. ### Step 4: define trust boundary Document: - which side is authoritative - where credentials live - which actions require approval - what happens on failure or timeout Never assume both OpenClaw instances share memory, sessions, or auth state. ### Step 5: implement with reversible changes Prefer: - isolated cron jobs - explicit webhook URLs - local config edits with backup - test messages before production use ### Step 6: verify end to end Check: - source event fired - delivery succeeded - receiver handled duplicate-safe logic - failure path is visible - no secrets leaked in logs or chat ## Output expectations When using this skill, produce one of these deliverables: - bridge design memo - message schema - cron payload definition - webhook contract - rollout plan with rollback - troubleshooting checklist ## Guardrails - Use only documented OpenClaw commands and delivery modes. - Do not claim native OpenClaw-to-OpenClaw federation unless the environment explicitly provides it. - Ask before publishing endpoints, changing firewall rules, or exposing dashboards. - Prefer fewer, larger writes over chatty loops when integrating with external services. - Keep communication auditable and easy to reason about. ## Quick examples ### Example: daily remote server audit to local operator Design: - remote OpenClaw runs a daily isolated cron job - job performs audit - delivery posts webhook to an operator-controlled endpoint or announces into a monitored channel - local OpenClaw summarizes findings for the user ### Example: deployment completion handoff Design: - build instance finishes deploy pipeline - sends webhook with environment, version, result, and log URL - receiving side creates a human-facing summary and asks for next action if needed


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)