MeshOps Control Plane

Operate and secure mesh workflows across gateways, including plugin install/setup, health verification, invite/join bootstrap, and controlled execution tasks...

Security Scan

The skill's code and runtime actions mostly match a mesh coordination purpose, but there are important mismatches and powerful runtime behaviors (automatic capability registration, remote installs, artifact download+extract, filesystem writes and gateway restarts) that are gated but can be surprising — the metadata/registry inconsistency and these side effects warrant caution.

Purpose & Capability

The files (handler.py and actions/*.sh) implement the described mesh control-plane capabilities (invite/join, capability publish, task delegation, preflight, deploy-skill, run-cmd, plugin setup). That runtime footprint is coherent with the skill description. However, the package-level registry summary earlier reported 'Required env vars: none' while the included metadata.yaml and SKILL.md declare multiple required env vars and binaries (OPENCLAW_* gates, jq, curl, tar, sha tools, openclaw CLI, etc.), which is an internal inconsistency and reduces transparency about what the skill will actually rely on.

Instruction Scope

SKILL.md and docs instruct agents to automatically register capabilities on load and to poll/claim tasks at the start of reasoning steps (automatic executor behavior). The scripts and handler read environment gating variables and may download artifacts, install plugins, write into /opt/openclaw/skills, and restart the gateway. Those behaviors are within the stated mesh/ops domain but expand the agent's runtime authority (auto-claiming and side-effectful installs), so operators must ensure gates and allowlists are configured as intended.

Install Mechanism

No install spec in the registry (skill is distributed as source files). The included scripts perform runtime downloads: deploy-skill uses curl to fetch arbitrary HTTPS artifacts (but enforces SHA256 and a gate), and setup-ansible-plugin invokes 'openclaw plugins install' which may fetch code from GitHub/npm/path. This is expected for a plugin/bootstrap skill, but it is a higher-risk runtime operation than a purely read-only instruction-only skill.

Credentials

The skill relies on multiple environment gates (OPENCLAW_ALLOW_HIGH_RISK, OPENCLAW_ALLOW_RUN_CMD, OPENCLAW_ALLOW_DEPLOY_SKILL), an allowlist (OPENCLAW_RUN_CMD_ALLOWLIST), and artifact path (OPENCLAW_ARTIFACT_ROOT). Those are proportionate to the high-risk capabilities, but the top-level registry metadata omitted required env vars while metadata.yaml lists them — a mismatch that could mislead operators. The skill does not ask for cloud credentials, but it does require filesystem and process permissions (writing to /opt, running openclaw CLI, restarting gateway).

Persistence & Privilege

always:false (no forced global inclusion). However, SKILL.md/docs specify automatic capability registration when a task-type skill loads and automated executor polling/claiming behavior, which effectively modifies shared mesh state and makes the agent an active participant in routing. This is consistent with a control-plane role but increases blast radius if gates/allowlists are misconfigured.

What to consider before installing

This skill appears to implement the MeshOps control-plane it claims, but review and operator caution are recommended before installing or enabling it in production: - Metadata mismatch: the marketplace/registry summary claims no required env vars, but metadata.yaml and SKILL.md expect several gating env vars and system binaries. Ask the maintainer to correct the registry metadata or treat the included metadata.yaml as authoritative. - Powerful runtime actions (download+extract, plugin installs, writing to /opt, restarting gateway) are present. They are gated by OPENCLAW_ALLOW_* flags and allowlists, but you should: - Keep OPENCLAW_ALLOW_DEPLOY_SKILL, OPENCLAW_ALLOW_RUN_CMD, and OPENCLAW_ALLOW_HIGH_RISK set to 0 until you audit the skill and its upstream plugin. - Populate OPENCLAW_RUN_CMD_ALLOWLIST narrowly (or leave empty) to avoid arbitrary command execution. - Restrict OPENCLAW_ALLOWED_CALLERS to trusted operator IDs only. - The skill will auto-register capabilities and may automatically claim tasks. If you do not want autonomous cross-gateway execution or capability advertisement, do not load this skill on agents that should remain passive. - Verify sources before permitting installs: setup-ansible-plugin calls 'openclaw plugins install' (github/npm/path). Confirm the plugin repository (https://github.com/likesjx/openclaw-plugin-ansible) and any artifact URLs used by deploy-skill. - Run preflight in a controlled environment first (the included preflight action reports presence of required binaries and current gate settings). Review the collected logs and test deploy flow in an isolated node before enabling on production gateways. If you want to proceed: require maintainer to fix registry metadata, audit the plugin repo and any artifacts, and enforce strict gate/allowlist settings and minimal privileges for the runtime user.

Ansible - MeshOps Coordination Skill

What This Is

Ansible is a distributed coordination layer that lets you operate across multiple OpenClaw gateways as one coordinated mesh.

Four pillars:

1. Ring of Trust: invite/join handshake, auth-gate WebSocket tickets, ed25519-signed capability manifests, per-action safety gates, and token lifecycle.
2. Mesh Sync: Yjs CRDT replication over Tailscale. Messages, tasks, context, and pulse remain durable across reconnects and restarts.
3. Capability Routing: publish/unpublish capability contracts. Each contract references a delegation skill (requester) and an execution skill (executor).
4. Lifecycle Ops: lock sweep, retention/pruning, coordinator sweep, and deployment hygiene.

Relationship Modes

• Friends/Employees (default): other nodes are different agents. Provide context and communicate explicitly.
• Hemispheres (advanced): mirrored instances of the same identity. Shared intent and direct communication.

Default to Friends/Employees unless explicitly told a node is a hemisphere.

Node Topology

• Backbone: always-on nodes (VPS/servers) that host Yjs WebSocket.
• Edge: intermittent nodes (laptops/desktops) that connect to backbone.

Human Visibility Contract (Required on Pickup)

When taking coordination work, maintain explicit lifecycle updates:

1. ACK: confirm receipt and summarize intent.
2. IN_PROGRESS: emit progress updates at meaningful checkpoints.
3. DONE or BLOCKED: close with evidence, next action, and owner.

Use conversation_id consistently for all related updates.

Ring of Trust - Behavioral Rules

• Unknown nodes require invite-based admission. Do not bypass.
• High-risk capability publishes require human approval artifacts.
• Respect caller gates (OPENCLAW_ALLOWED_CALLERS) and high-risk flags.
• Never expose tokens in plaintext messages/logs/shared state.
• When signature enforcement is on, only accept manifests signed by trusted publisher keys.

Gateway Compatibility Contract

• Validate plugin is installed and readable before assuming tool availability.
• Verify tier assumptions (backbone vs edge) before mutating coordination settings.
• Treat gateway runtime as source of truth for active topology and health.

Reliability Model

Source of Truth

Shared Yjs state is authoritative.

Delivery Semantics

• Durable: messages/tasks persist in shared state.
• Auto-dispatch: best-effort realtime injection into sessions.
• Heartbeat reconcile: periodic rescan recovers missed injections.
• Retry: transient dispatch failures retry with bounded backoff.
• Send receipts: notify configured operators when work is placed on mesh.

Operating Rules

• Verify pending work with ansible_status and ansible_read_messages.
• If polling mode is used, always reply via ansible_send_message.
• Use corr:<messageId> for thread continuity.
• Listener behavior is optimization; sweep/reconcile is the backstop.

Capability Contracts

• A capability is a contract, not just a label.
• Contract includes delegation and execution skill references.
• Publishing updates routing eligibility mesh-wide.
• Provenance is verified against trusted publisher keys when configured.
• High-risk contracts require explicit approval artifacts.
• Unpublish removes eligibility immediately.
• Lifecycle evidence must capture install/wire outcomes.

Delegation Protocol

1. Requester creates task with objective, context, acceptance criteria, and target policy (to_agents or capability).
2. Executor claims task and sends acceptance/ETA signal.
3. Executor performs work, emits progress, and completes with structured result.
4. Requester reports final outcome to human and/or downstream agents.

Coordinator Behavior

• Run sweep loops for stale locks, SLA drift, and backlog reconciliation.
• Prefer record-only escalation by default when blast radius is unclear.
• If DEGRADED, prioritize containment, visibility, and deterministic recovery.

Available Tools

Communication

Tool	Purpose
ansible_send_message	Send targeted or broadcast message across mesh
ansible_read_messages	Read unread messages (or full history)
ansible_mark_read	Mark messages as read
ansible_delete_messages	Admin-only emergency purge

Task Delegation

Tool	Purpose
ansible_delegate_task	Create task for another node/agent set
ansible_claim_task	Claim pending task
ansible_update_task	Update task status/progress
ansible_complete_task	Complete task and notify requester
ansible_find_task	Resolve task by ID/title

Context and Status

Tool	Purpose
ansible_status	Mesh health, unread, pending, and topology summary
ansible_update_context	Update shared context/threads/decisions

Coordination and Governance

Tool	Purpose
ansible_get_coordination	Read coordinator configuration
ansible_set_coordination_preference	Set node coordinator preference
ansible_set_coordination	Switch coordinator (guarded)
ansible_set_retention	Configure closed-task retention/pruning
ansible_get_delegation_policy	Read delegation policy plus ACKs
ansible_set_delegation_policy	Publish/update delegation policy
ansible_ack_delegation_policy	Acknowledge policy version
ansible_lock_sweep_status	Inspect lock sweep health

Capability Lifecycle

Tool	Purpose
ansible_list_capabilities	List published capability contracts
ansible_capability_publish	Publish/upgrade capability contract
ansible_capability_unpublish	Remove capability from routing
ansible_capability_lifecycle_evidence	Show install/wire evidence for version
ansible_capability_health_summary	Show success/error/latency summary

When to Use Ansible

Use Ansible when work crosses gateways, needs durable coordination, or requires auditable delegation contracts.

Session Behavior

• Start by checking status and pending work.
• Prefer explicit delegation for capability-matched work.
• Keep humans in loop via lifecycle messages.

Message Protocol v1

• Always include enough context for independent execution.
• Use stable correlation IDs (corr) and conversation IDs.
• Prefer structured payloads over freeform-only messaging.

Setup Playbooks

Follow plugin setup and gateway runbooks for topology bootstrap, auth-gate, and trust settings.

Delegation Management

• Keep delegation policy current and acknowledged across nodes.
• Treat capability publishes as contract releases.
• Roll back quickly when lifecycle evidence indicates drift or misfire.