ClawHosters
by Daniel Samer
7 min read
ClawHub hit 44,000 community skills in April 2026. That's wild growth for a registry that didn't exist six months earlier. But here's what nobody tells you: building your own skill takes about 10 minutes. Maybe less.
A skill is just a folder with a SKILL.md file inside it. Two required YAML fields, some markdown instructions, and you're done. No TypeScript, no compilation step, no framework to learn. If you can write a clear set of instructions for a coworker, you can write an OpenClaw skill.
I'm going to walk you through the full cycle. Building one, testing it on your instance, and getting it onto ClawHub if you want to share it.
What Goes Inside SKILL.md
The official OpenClaw docs describe the format pretty clearly, but most tutorials skip the advanced fields. So here's the complete picture.
Every SKILL.md starts with YAML frontmatter between --- delimiters, followed by a markdown body. The frontmatter tells OpenClaw what your skill is. The markdown body tells the agent what to do.
---
name: deploy-checker
description: Verifies deployment health after pushing to production
version: 1.0.0
user-invocable: true
metadata: {"tags": ["devops", "deployment"], "homepage": "https://github.com/you/deploy-checker"}
---
Two fields are required: name and description. Everything else is optional but useful.
A few things that trip people up. The metadata field must be single-line JSON. Not multi-line YAML. If you write it across multiple lines, the parser silently fails and your tags disappear. I've seen this bite at least four developers in GitHub issues. Just keep it on one line.
The user-invocable: true flag makes your skill available as a slash command. Without it, the agent can still use the skill autonomously when it matches, but you can't trigger it manually. Set disable-model-invocation: true if you want the opposite: a skill that only runs when you explicitly call it, never autonomously. Handy for destructive operations.
The Markdown Body
This is where you teach the agent. Think of it as a runbook. What should the agent do? What inputs does it need? What are the steps? What does good output look like?
Be specific. "Help the user with deployments" is a bad instruction. "Check the health endpoint at /api/health after each deployment, report the status code and response time, and flag anything over 2 seconds" is a good one.
You can also add a scripts/ directory for shell helpers and a references/ directory for context files. But most skills don't need them.
Skills vs. Plugins: When Do You Need TypeScript?
The v2026.5.18 release introduced defineToolPlugin and three CLI commands (openclaw plugins build, validate, init) for a separate plugin track.
The distinction is simple. Skills are markdown instructions. They guide the agent through natural language. Plugins are TypeScript code that runs inside the Gateway process with access to internal APIs.
Use a skill when you want to teach the agent a workflow, enforce a process, or add domain knowledge. Use a plugin when you need deterministic behavior that can't be left to model judgment, like registering a new channel or wiring up a custom provider.
Probably 90% of what people build should be a skill. Plugins are for when you've hit the limits of natural language instructions. If you're not sure which you need, start with a skill.
Testing Your Skill Locally
Drop your skill folder into ~/.openclaw/skills/ (global) or .openclaw/skills/ in your project (workspace-level). Workspace skills override global ones with the same name.
Three ways to test:
Interactive chat. Just start a conversation and see if the agent picks up your skill. Ask it to do the thing your skill describes. If the response looks right, you're on track.
Slash command. If you set user-invocable: true, type /deploy-checker (or whatever your skill name is) directly. Faster feedback loop than waiting for the agent to match.
Headless CLI. Run openclaw --skill deploy-checker --input "check staging" for automated testing without the interactive session.
One tip that saves a lot of time: enable the watcher with skills.load.watch in your config. It hot-reloads your SKILL.md whenever you save changes. Without it, you're restarting the daemon after every edit.
If you run a ClawHosters managed instance, you can install skills directly from the dashboard without touching the CLI. But for development, local testing is faster.
Publishing to ClawHub
Once your skill works, publishing takes one command:
clawhub skill publish ./deploy-checker --slug deploy-checker --version 1.0.0
ClawHub runs your skill through VirusTotal's Code Insight scanning. You'll get one of three labels: Benign, Suspicious, or Malicious.
Here's the honest part. That scanning catches less than you'd hope. A Nerdbot audit of 1,024 skills found VirusTotal detected only 4 of 177 malicious ones (2.3%). OpenClaw's own team called it "not a silver bullet". So the scanning exists, but community trust still depends on people reading the actual SKILL.md before installing.
If your skill uses shell commands, file access, or network calls, expect the possibility of a false positive. Legitimate skills get flagged sometimes. Document why your skill needs those permissions in the SKILL.md itself, and if you do get flagged, use the Rescan feature and wait for maintainer review.
Security: Read Every SKILL.md Like Code Review
Back in January 2026, Koi Security found 341 malicious skills on ClawHub. That was 11.9% of the entire registry at the time. The attack pattern was clever: professional-looking documentation with "prerequisites" sections that told users to run attacker-supplied shell commands.
As a skill author, you're on the trustworthy side of this. But you should know what the landscape looks like, because your users will be cautious. Be transparent about what your skill does and why. If your skill needs exec access, say so upfront and explain the reason.
For your own instance, whether you're self-hosting or running on ClawHosters, don't install skills blindly. Read the SKILL.md. Check what commands it asks the agent to run. Look at the publisher's history. Treat it like a code review, because that's what it is.
