$ ssh clawdbot.space --loading...
$ ssh clawdbot.space --loading...
Build, test, and publish your own OpenClaw skills — from local scripts to ClawHub packages.
Skills are the building blocks of OpenClaw automation. While ClawHub offers thousands of community skills, building your own lets you create perfectly tailored automation. This guide covers the full lifecycle: scaffolding, development, testing, and publishing.
| File | Purpose | Status |
|---|---|---|
| SKILL.md | The whole skill. YAML frontmatter carries name and description (both required); everything below is Markdown telling the model when and how to act. | Required |
| assets alongside it | Scripts, templates or reference files the instructions point at. Optional — many useful skills are a single SKILL.md and nothing else. | Optional |
| scripts/ | Helper scripts (Python, Bash, Node) that the skill can invoke via tool calls. | Optional |
| templates/ | Template files for code generation, config scaffolding, or document creation. | Optional |
| tests/ | Test scenarios to verify skill behavior before publishing. | Recommended |
Skills are folders under the workspace skills root. There is no scaffold command — the folder and one file are the whole structure.
mkdir -p ~/.openclaw/workspace/skills/my-skill
One file, two required frontmatter fields. The description is what the model reads when deciding whether this skill is relevant, so write it as an answer to "when should I use this?"
# ~/.openclaw/workspace/skills/my-skill/SKILL.md
---
name: my-skill
description: Generates a standup report from yesterday's commits and completed tasks.
---
# Daily Standup Generator
Use this when the user asks for a standup, a daily summary, or
"what did I do yesterday".
## Steps
1. Read memory for tasks completed in the last 24 hours.
2. Run `git log --since="24 hours ago" --oneline` in each active repo.
3. Format as Done / Doing / Blockers.
4. Write to reports/standup-{date}.md.Write instructions like you're teaching a new team member. Avoid ambiguity. List exact steps, expected formats, and error handling.
There is no dependency block to pin. If the skill depends on a tool version, say so in the Markdown body so the model surfaces it rather than failing halfway.
Request only the tools your skill actually needs. Fewer tools = smaller attack surface.
Tell the agent what to do when things fail: retry logic, fallback behavior, error messages to the user.
Try the phrasing a real user would type. A skill that only fires when invoked as /skill has a description problem, and that is the half most people do not test.
Run the agent against a phrase that should trigger the skill. This tests the description as much as the body.
openclaw agent --message "generate my standup"Invoke it by name from a chat. If this works but the natural-language phrasing does not, the skill is fine and the description is the problem.
/skill my-skillThere is no dry-run flag. To keep a skill from having side effects while you test it, restrict what it can reach with the tool policy — deny wins over allow.
openclaw config get toolsConfirm the gateway actually picked the skill up. Skills load when a session starts, so run /new first if you just wrote the file.
openclaw skills listPublishing is a separate authenticated tool. `openclaw skills` has no publish subcommand.
clawhub loginThe path is the folder containing SKILL.md. --version, --changelog and --tags are available.
clawhub skill publish ./my-skill --slug my-skillInstalling back from the registry is how you check the published bundle is what you meant to ship.
openclaw skills install @you/my-skill