Skip to main content
A skill is a small folder an agent can load mid-turn. It is the mechanism by which an agent remembers how you like things done. When a matching task shows up, the agent reads the skill, follows the instructions, and runs any helper scripts the skill ships with. Every skill lives in the agent’s workspace under .openclaw/workspace/skills/<name>/. The Skills page in the dashboard is a flat, searchable catalog of every workspace skill across your fleet, deduplicated so the same skill installed on 40 instances shows as one row with an avatar stack.

​
What a skill looks like

composer/
├── SKILL.md           # when to use it, instructions, metadata
├── scripts/           # small helpers the agent can invoke
│   ├── render-score.sh
│   └── stem-split.py
└── references/        # docs the agent loads on demand
    └── style-guide.md
The SKILL.md is the entry point. It carries YAML frontmatter (name, description, license, allowed tools) followed by prose instructions. Scripts are the deterministic building blocks: a curl wrapper, a small Python transform, a shell utility. References stay out of the main file until the agent asks for them, which keeps SKILL.md short enough to sit in context.

​
Creating a skill with Operator

You do not write skills by hand. Describe what you want in chat: 
I keep asking you to draft tweets in my voice. Turn that into a skill
called tweet-draft. Include the tone notes we landed on last week and a
reference list of my favourite openers.
Operator builds the skill, shows you a preview with a file tree and the rendered SKILL.md, and asks which agent to deploy it to. The preview lives in the chat as a card with a file picker on the left and the content on the right. Once you pick an agent and click Deploy, the skill installs on that agent’s workspace and shows up in the Skills sidebar.
If the same skill already exists on the chosen agent, the preview asks whether to overwrite it.

​
Skills vs native orchestration

Skills are not an orchestration layer. The agent’s runtime has its own tools for multi-step work: spawning subagents, yielding to wait on them, messaging peers, structured LLM calls, and scheduled jobs. Skills carry durable knowledge (a style guide, a domain checklist, a prompt chain you like) and durable building blocks (a small CLI helper). They are not the right place for long-running waits or cross-restart state.
Use a skill whenUse native orchestration when
Activation content the agent re-reads at turn timeMulti-step work that needs to outlive the turn
A deterministic helper script the agent calls mid-turnIterating with judgment on each step of a list
A style guide, checklist, or brand voiceDurable waits, cross-restart resumes, managed flow state

​
The Skills page

Search

Filter the sidebar by name or description. Works across every agent.

Per-instance filter

Narrow to one or more agents when the fleet gets big.

Instance switcher

Jump between copies of the same skill on different agents.

File viewer

Expand any skill to read its SKILL.md and scripts inline.
A left sidebar holds the list with a + button to start a chat about creating a skill. The right pane renders the selected skill: name, description, metadata grid (license, version, author, allowed tools), a short body preview, and a collapsible file tree you can step through tab by tab. Markdown files come with a rendered/raw toggle. Scripts render as plain monospace.

​
Empty states

If an agent has no workspace skills yet, the page shows a single explanation panel and a Create a skill with Operator button that drops you into chat pre-filled with a short setup prompt. If you have no active agents, the page says so and routes you to spin one up first.

Operator agent

Who writes skills for you

Agents

Skills ride alongside each agent

Files

Skills live in the agent’s workspace