ClawHub, the skill registry for OpenClaw, now hosts thousands of community-built skills. That's the problem: browsing "clawhub skills worth installing" turns into an afternoon of reading SKILL.md files that all promise the same three things. Most of them solve a real problem. A lot of them solve the same problem worse than something already on your machine.
Here's an honest shortlist, organized by the actual problem each skill solves rather than by star count or hype. If a skill doesn't clearly earn its slot in your agent's context window, it's not on this list.
How to think about "worth installing"
Every OpenClaw skill costs you something even before it does anything: it sits in the eligible-skills snapshot loaded into the system prompt at session start, and its full body loads into context the moment the agent decides it's relevant. A skill that's 90% generic advice and 10% a working command is a bad trade. The skills below all clear a simple bar:
- They wrap a CLI or API your agent can't reliably improvise.
- The instructions are specific enough that the agent doesn't need to guess flags.
- Uninstalling them would remove a capability, not just a paragraph of prompt padding.
Install via the standard command:
clawhub install <skill-slug>
Communication: give your agent a way to actually reach someone
The skills that get real use aren't the ones that summarize a chat — they're the ones that let an agent talk to another agent it doesn't share a codebase with. This is a genuinely underserved category on the registry, and it's where the pilot-* family fits.
pilot-protocol (by teoslayer) is the core skill worth starting with here. It wires up pilotctl, a CLI that gives an agent a permanent virtual address, encrypted UDP tunnels with NAT traversal, and an explicit per-peer trust handshake — meaning "on the network" and "trusted by you" are two separate states, unlike a VPN where joining the network implies mutual access. One install pulls in the daemon and the addressing model; everything else in the family builds on top of it.
From there, pick only what you need:
- pilot-chat — direct 1:1 messaging between agents once trust is established.
- pilot-group-chat — multi-agent conversations with membership tracking, useful if more than two agents need to coordinate on a task.
- pilot-directory — a locally cached list of known agents, so you're not re-resolving addresses on every run.
The honest caveat: these only pay off once you actually have peers worth talking to. If your agent operates alone, skip the whole family. If it's coordinating with other agents — your own fleet, or third parties — this is one of the few registry categories addressing that gap directly, and it's worth the install specifically because "agent talks to a different agent's daemon, with consent on both sides" isn't something you can shell-script your way into safely.
File sync: skills that replace ad-hoc scp
pilot-sync and pilot-dropbox solve a problem that otherwise turns into a pile of one-off scripts: keeping a folder consistent across agents without a shared filesystem. pilot-sync does bidirectional sync over an established trust link; pilot-dropbox is the pub/sub-based auto-syncing version if you want push-on-change rather than periodic sync. Both assume pilot-protocol is already installed for the transport and trust layer — check that dependency before installing, since a skill that silently no-ops without its prerequisite wastes a session figuring out why.
For resumable large-file transfer specifically (model weights, datasets), pilot-chunk-transfer is the more targeted pick over general-purpose sync — it does integrity checking and resume, which matters once a transfer is big enough to fail partway through.
Trust and verification: the category people skip and shouldn't
This is the category most likely to get skipped because it doesn't feel urgent until it is. If your agent is going to accept files, run commands suggested by another agent, or act on messages from a peer, verifying who's on the other end isn't optional.
- pilot-verify — checks identity and reachability before your agent acts on anything from a peer. Cheap to run, and it's the difference between "an agent I approved sent this" and "something claiming to be that agent sent this."
- pilot-auto-trust — lets you define a policy (allowlist, known-network) instead of hand-approving every handshake, useful once you have more than a couple of regular peers.
- pilot-blocklist — shared blocklists of agents that other trusted peers have flagged. Worth it precisely because trust decisions compound; one bad actor caught by a peer saves you the same discovery.
Skip pilot-quarantine and pilot-watchdog unless you're actually running a fleet of agents talking to unfamiliar peers regularly — for a single agent with two or three known collaborators, the overhead isn't justified yet.
The rest of the registry: install selectively, not by category
DataCamp's rundown of the broader registry is a good reference point for the non-networking categories — duckdb for CSV/Parquet analytics without loading raw data into context, github for wrapping the gh CLI, debug-pro for structured debugging methodology. Those earn their slot the same way the pilot skills do: they replace something your agent would otherwise botch through improvisation. The DevOps category is worth extra scrutiny before installing anything — shell access skills are exactly where a skill that's slightly wrong about a flag can do real damage, so read the SKILL.md body, not just the description, before trusting it with docker or kubectl.
The actual test before you install anything
Before adding any ClawHub skill, ask one question: does this skill replace a capability, or does it replace a Google search? Skills like pilot-verify or duckdb wrap something your agent genuinely can't do reliably on its own (cryptographic identity checks, a real query engine). A skill that's mostly restating public documentation in the agent's voice is dead weight in your context window — uninstall it and let the agent search when it needs that information.
If you're building the agent-to-agent side of this — messaging, trust, file exchange between separate agents rather than tools bolted onto one — it's worth looking at Pilot Protocol's skill catalog directly. It documents the full pilot-* family beyond what's summarized here, including the communication, discovery, and integration-bridge categories, and shows how the pieces compose once pilot-protocol is installed as the base layer.
FAQ
Is ClawHub only for OpenClaw?
Yes — ClawHub is the skill registry specifically for OpenClaw agents. Skills are SKILL.md files with YAML frontmatter plus a markdown body of instructions, loaded into the agent's context when relevant.
Do I need to install every skill in a family (like all the pilot-* skills)?
No. Install the base skill (pilot-protocol) and only the specific capability skills you need. Installing skills you don't use adds to what the agent has to evaluate as "eligible" at session start for no benefit.
How is trust handled between two agents talking over Pilot Protocol?
Membership on the network and trust are separate: reaching another agent's address doesn't mean it accepts messages from you. Trust requires an explicit per-peer handshake that both sides approve before a tunnel is used either way.
What if a skill I want depends on another skill or a running daemon?
Check the skill's listed dependencies before installing — several of the pilot-* skills explicitly require pilotctl and a running daemon (from pilot-protocol) to function, and will silently do nothing without them.
Get started with the agent networking layer directly: curl -fsSL https://pilotprotocol.network/install.sh | sh
Top comments (0)