30-second overview
| Item | Details |
|---|---|
| What a skill is | Something you do often, packaged as a reusable capability |
| When to turn it into a skill | The third time you do the same thing |
| Is more always better? | No — it makes the agent pick the wrong one |
| After a reset and rebuild | They have to be installed again |
| Most common problem | It's installed but the agent doesn't use it |
Introduction
The skills system in OpenClaw lets you extend what your agent can do. You can install community-built skills from ClawHub, or write your own.
What is a skill?
A skill is a set of predefined instructions, tools and files that let the agent handle a specific task more precisely. For example:
- 🌐 web-search — search the web and pull the results together
- 📊 data-analysis — data analysis and chart visualization
- 📧 email-assistant — email management and automatic replies
- 🔧 code-reviewer — code review and suggestions
How to install a skill
- Open the OpenClaw Dashboard (how do I get there?)
- Click "Skills" in the left-hand menu
- Browse the available skills, or search for a specific name
- Click "Install"
- Once installed, the agent loads the new skill automatically
Installing from ClawHub
- Go to ClawHub.ai
- Search for the skill you need
- Copy the install command (usually a URL)
- Paste it into the Skills page in the OpenClaw Dashboard
Custom skills
You can also create custom skills inside your workspace. Just create a SKILL.md file under the .openclaw/skills/ directory and define the skill's instructions and behavior there.
Advanced tip: a custom skill can include scripts, examples and resource files, so the agent can handle more complex, specialized tasks.
Related guides
Where skills end and workflows begin
A common confusion: when should something be a skill, and when should it be an automation tool?
| Characteristic | Use a skill | Use n8n |
|---|---|---|
| Steps | Need judgment in the moment | Fixed |
| Trigger | When you ask for it | A schedule or an event |
| How often it runs | Irregularly | Frequently |
| Reliability requirement | Medium | High |
A simple way to split them: "things I do when I think of them" are skills; "things that should happen when the clock says so" belong in an automation tool.
Two habits for maintaining skills
1. Keep a list. What you installed and what each one does. After a reset and rebuild, that list is what you reinstall from.
2. Clear out the ones you don't use. An unused skill doesn't just take up space; it raises the odds the agent picks the wrong one. If you haven't used it in three months, consider removing it.
What problem do skills solve?
Without skills, you have to give the full instructions every single time — the background, the format requirements, the output style. Do the same thing ten times and you've typed the same explanation ten times.
A skill pins that part down. After that you just say "run that one" and it knows the whole procedure.
The test for whether something should be a skill is simple: the third time you do the same thing, package it. Something you've only done once or twice is still changing, and pinning it down too early just ties your hands.
Installing too many backfires
Intuitively more skills means more capability. In practice it's the opposite.
The agent decides which skill to use from the skill descriptions. The more skills there are, the more those descriptions overlap, and the higher the chance it picks the wrong one. And picking wrong is hard to diagnose — it does something that looks related but isn't what you wanted.
The better approach is to start with as few as possible and add more once the behavior is stable. When you notice it starting to pick wrong, the first thought shouldn't be "write another, more precise skill" but "are the boundaries between two of these skills too blurry?"
The description decides whether it gets used
| How it's written | Result |
|---|---|
| "Organize data" | Too vague — the agent doesn't know when to use it |
| "Group order data from a CSV by date and output it in monthly report format. Requires a CSV file." | Clear — it knows when to use it, what it needs and what it produces |
The principle: write it for a new colleague who has never seen your work.
FAQ
Q: I installed a skill but the agent doesn't use it — why?
Nine times out of ten the description is too vague. Rewrite it as "when to use this, what it needs, what it produces" and try again. If it still doesn't get used, check whether another skill's description is too similar.
Q: How many can I install?
There's no hard technical limit, but in practice, once you're past a dozen or so, it's time to look for overlap. The cost of picking wrong is higher than the cost of having one fewer skill.
Q: Do skills survive a reset and rebuild?
No. Installed skills are among the things that get wiped, so you reinstall them after a rebuild. We recommend keeping a separate list; see the reset and rebuild guide.
Q: Do skills consume resources?
A skill itself is very light; what consumes resources is what it executes — especially skills that need to open a browser. Choosing a plan is covered in what it can and can't do.
Q: How do I know which skill it used?
Look at the execution log. Every "it did the wrong thing" investigation starts here — first confirm which skill it picked, then decide whether it picked wrong or the skill itself is the problem.
Skills aren't a universal entry point
A common expectation is "once I install a skill it'll just do it for me". In reality a skill is called, not triggered — it only acts when you ask.
If you want something to happen automatically at a set time, that's scheduling, and it belongs in an automation tool. The dividing line is in the table above.
Start with one skill
Don't install five at once. Install one that you'll genuinely use this week, use it a few times, and confirm it behaves the way you expect.
"It picked the wrong one" problems only start appearing from the second skill onwards, and by then you have a baseline to compare against, so you know whether the problem came with the new one or was there all along.
Two ways skills stop working
1. The web page it depends on gets redesigned. Skills that scrape data hit this most often — the layout changes and the original steps can no longer find their target. That's an inherent limitation of browser automation.
2. Your requirements changed and the skill didn't. A skill pins a procedure down; the benefit is consistency, the price is that it doesn't evolve along with your needs. After using one for a while, it's worth going back to check whether the procedure you pinned down is still the one you want.
What shouldn't be a skill
- Things you've only done once or twice — they're still changing, and pinning them down early ties your hands
- Things where the conditions differ every time — a skill's value is in repetition, and too many variables defeat the point
- High-frequency fixed procedures — those belong in an automation tool, not waiting for you to ask
Want someone to build it for you?
If you'd rather not assemble these workflows yourself, or the scale is big enough that you want someone planning it with you, Roamer Tech (RoamerHost's parent company) takes on contract work in business process automation and AI agents:
