This entry uses the node-connect skill from the openclaw/openclaw repository. The agent behavior is diagnostic and narrow: determine the intended topology, inspect the gateway route OpenClaw is actually advertising, compare that route to the failure mode, and recommend one concrete fix path for pairing or authorization problems. It is a troubleshooting runbook, not a platform listing.

Invoke this instead of using the product normally when a user is blocked by setup failure. Typical triggers include QR setup codes that do not connect, manual host and port connections that work on local Wi-Fi but fail on a VPS or tailnet, stale bootstrap tokens, pairing requests that are pending but unapproved, or confusing errors around gateway.bind, gateway.remote.url, Tailscale, and public pairing URLs. In those moments the task is not “use OpenClaw,” it is “diagnose why node-to-gateway connectivity is broken.”

The scope boundary is what keeps this skill-shaped. It does not try to describe the whole OpenClaw project, companion apps, or node feature set. It focuses on a single operator job: find the real route from node to gateway and fix auth or pairing in that path. That boundary prevents it from being just another platform, SDK, or server entry.

Integration points are the OpenClaw CLI commands the runbook centers on, including openclaw qr --json, device approval checks, gateway config inspection, and optional Tailscale status verification. It belongs in diagnostics and connectivity support workflows.