The Complete OpenClaw Skills List: Every Built-In Skill Explained (2026)

Skills vs. Plugins: Why the Distinction Matters

Claude Code has a plugin ecosystem. Cursor has extensions. VS Code has its marketplace. The pattern is the same everywhere: capabilities are added through third-party packages that live outside the core system, maintained by strangers, and frequently break on updates.

OpenClaw Skills work differently. A skill is a plain-text SKILL.md file — a set of instructions the agent reads at the start of a relevant task. No compilation. No version pinning. No dependency tree. If you can describe a process clearly in English, you can write a skill. The agent follows it the same way it follows any other instruction, which means skills compose naturally with everything else: cron jobs, sub-agents, memory, browser control.

The practical difference: when Claude Code's GitHub plugin breaks, you wait for a package maintainer. When an OpenClaw skill has a problem, you open the SKILL.md and fix one line of text. That's the whole philosophy compressed into a single comparison.

How Skills Actually Work

Every OpenClaw session loads the available skill list automatically. The agent scans each skill's <description> tag and pattern-matches against the user's request. When one skill clearly matches — and only one — it reads the full SKILL.md before doing anything else. Multi-step, tool-heavy tasks (GitHub PRs, email replies, weather lookups) get handled correctly from the first message, without the user needing to specify a mode or prefix a command.

Skills live in two places:

Workspace skills override built-in skills with the same name, so you can customise any skill's behaviour without touching the global install. This matters more than it sounds — it means you can ship a stricter version of the GitHub skill that always requires PR descriptions, or a weather skill that only ever uses Celsius and returns five-day forecasts, and it stays that way across every update.

Core Skills (Built-In)

These ship with every OpenClaw install. If you have OpenClaw, you have all of these.

Workspace Skills (Community)

These ship separately and live in ~/.openclaw/workspace/skills/. They're typically API-specific integrations or more opinionated workflows. You install them by dropping the skill directory in place — no package manager, no npm.

Natural Language Triggers: How Selection Actually Works

Skills aren't slash commands. You don't type /github pr list. You just say "show me the open PRs on my main repo." The agent reads the skill descriptions, pattern-matches against intent, and picks the one that fits.

The selection logic has one hard rule: if more than one skill could apply, the agent picks the most specific one and reads only that file. This keeps context lean. A request like "summarize this podcast episode" triggers summarize, not openai-whisper-api — even though both deal with audio. The distinction: summarize handles URLs and can delegate to Whisper internally; it's the right entry point.

Where the system is genuinely bad: skills with overlapping descriptions can confuse the selector. If you have a workspace skill that overrides a built-in with a poorly-written description tag, you'll get silent misfires. The fix is to write tight, specific descriptions — not marketing copy. Use when: X. NOT for: Y. is the correct format.

What the Community Is Saying

"Claude Code Unpacked" landing at #1 on Hacker News this morning with 9 comments in under an hour is telling — people are hungry to understand what their AI coding tools are actually doing under the hood, not just what the marketing page claims. On r/LocalLLaMA, the running theme lately is frustration with capability gaps: agents that confidently claim tool access they don't actually have, or that silently fail when an integration breaks. Reddit's ML community has been comparing tool-use implementations across Claude, GPT-4.1, and Gemini 2.5 Pro — the consistent finding is that structured tool definitions (like SKILL.md's precise use/not-for framing) produce significantly fewer ambiguous selections than free-form plugin descriptions. Meanwhile on X, the developers seeing the most consistent output from agentic setups are the ones who treat their skill/tool library as first-class code: versioned, documented, tested. The pattern that's emerged: if you can't describe what a skill does in two sentences with concrete exclusions, neither can your agent.

Build Your Own Skill in 15 Minutes

The minimum viable skill is three files: a directory, a SKILL.md, and optionally a scripts/ subfolder for any shell or Python helpers. Here's the structure that actually works:

A few things worth knowing before you start writing. Skills are read at the beginning of a task — they're instructions, not wrappers. The agent will follow them the same way it follows any other context, which means if your skill says "always confirm before deleting," it will actually always confirm before deleting. Scripts in the scripts/ directory should be referenced by path from the SKILL.md, not assumed to be in PATH.

The fastest way to get a working skill is to use the skill-creator skill itself: just say "create a skill that does X" and it'll scaffold the whole thing. Then you review and edit. Takes about five minutes for anything non-trivial. See also: How to Build Custom OpenClaw Skills.