| 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:
- Source OpenClaw runs an isolated cron or task.
- Delivery mode is
webhook.
- 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:
- Instance A sends a structured message to a human-controlled channel.
- Human or downstream automation forwards or triggers Instance B.
- 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:
- Source instance schedules a cron job.
- Cron produces either an announcement or webhook.
- 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
