OpenClaw Skills vs Plugins: Decide by Ownership

The browser on this OpenClaw host is both a skill and a plugin. The skill is named browser-automation; it tells the agent how to control pages, manage tabs, and recover from stale references. The plugin is named browser; its manifest owns the browser tool that performs those operations. One feature, two extension surfaces, no contradiction.

That retained result breaks the usual shortcut for explaining OpenClaw skills vs plugins. “Skills are local knowledge; plugins connect external services” sounds tidy, but it assigns the boundary to network geography. Current OpenClaw does not. A skill can instruct an already network-capable tool. A plugin can add a local model provider, channel, hook, service, command, or browser runtime without fronting a SaaS API.

The reliable question is narrower: which boundary must this change own? If the answer is agent behavior—when to use a tool, what evidence to collect, how to format a result—the change belongs in a skill. If OpenClaw must load new runtime machinery, the change belongs in a plugin. If the machinery is easy to misuse, ship both.

Failure modes of the old mnemonic

The host probe returned 55 skill records and 72 plugin records. Those numbers are not a catalog score; they are useful because the two inventories expose different facts. Skill rows reported eligibility, model visibility, source, and missing requirements. Plugin rows reported enablement, load status, origin, format, contracts, and runtime-owned surfaces.

For the browser pair, the skill row was eligible and model-visible. Its source was an extra skill directory. The plugin was bundled, enabled, and loaded; its contracts.tools contained browser. The instruction layer could be inspected without pretending it implemented a browser. The runtime layer could be inspected without pretending it explained a robust browsing workflow.

This distinction matters when something fails. A perfect SKILL.md cannot repair a tool that was never registered. A loaded tool does not guarantee the agent will apply the right sequence, collect the right evidence, or stop at the right boundary. Debugging gets cheaper when those failures are not collapsed into “the extension is broken.”

Decide by ownership, not by packaging folklore

These tests classify awkward cases better than “local versus external.” Suppose an agent already has an authenticated command-line client for an external service. A skill may be enough because no new runtime surface is required; the value lies in target selection, dry-run rules, and the shape of a reviewable receipt. The network call does not magically turn that instruction package into a plugin.

Now reverse it. A local speech provider needs discovery, lifecycle, configuration, and a registered provider contract. Nothing about that work is “external,” yet it is plugin work because OpenClaw must load code and expose a runtime capability. Geography has no diagnostic value here.

A skill changes how the agent uses available capability. A plugin changes the capability OpenClaw can load. Packaging both is normal when the new capability also needs a disciplined method.

What a skill owns in current OpenClaw

A skill is a directory built around SKILL.md. Its frontmatter names and describes the skill; the markdown body supplies instructions. Supporting scripts, references, and assets may live beside it, but those files do not become a resident Gateway extension merely because they are present. The agent follows the skill and invokes allowed tools when work is required.

The current loader is more deliberate than the old “drop it under one home directory” description. Workspace skills have the highest precedence, followed by project-agent, personal-agent, managed, bundled, and extra-directory or plugin-provided skills. Same-name collisions resolve by that order. Eligibility may also depend on binaries, environment, configuration, operating system, and an agent’s skill allowlist.

That makes skills well suited to operating policy that benefits from plain review:

• a release note workflow that requires a source diff, compatibility callout, and reviewer receipt;
• an incident triage method that names the allowed probes and the escalation threshold;
• a support reply process that separates facts, suggested action, and unresolved uncertainty;
• a browser procedure that records a semantic snapshot before clicking and checks console and network evidence after the action.

None of those examples proves the underlying tool is permitted. The official skill documentation is explicit about the security boundary: a skill allowlist controls visibility to the agent, not host shell authorization. If the agent still has broad exec access, hiding one skill does not remove the commands that skill would have described. Sandbox policy, tool policy, OS isolation, and scoped credentials must enforce authority outside the prose.

What a plugin owns in current OpenClaw

A native OpenClaw plugin has an openclaw.plugin.json manifest and a runtime module. The manifest declares identity, activation and static contracts; the runtime registers the implementation. Plugins can own far more than MCP servers: messaging channels, model and media providers, CLI backends, tools, hooks, background services, Gateway methods, commands, search, fetch, speech, and generation surfaces all fit the current model.

OpenClaw also recognizes compatible bundles from Codex, Claude, and Cursor layouts. That compatibility path can map skills, commands, hooks, and bundle metadata into the plugin inventory. “Plugin” therefore names a managed extension package, not one fixed manifest copied from an older ecosystem.

The runtime lifecycle introduces obligations that skills do not have. Installing or changing plugin code requires the Gateway serving the conversation to reload or restart. A cold plugins inspect can prove that a manifest and registry entry exist; it does not prove the already-running Gateway imported that version. For live failures, runtime inspection is the stronger receipt.

openclaw skills info browser-automation --json
openclaw skills check --json

openclaw plugins inspect browser --runtime --json
openclaw gateway status --deep --require-rpc

The split is useful during rollout. If the tool contract is absent from runtime inspection, editing the accompanying skill is noise. If the tool is registered but the agent chooses it at the wrong time or returns an unreviewable result, the skill is the likely repair surface. Each command answers one question instead of producing an undifferentiated green check.

“Both” is a designed state, not a compromise

The current skill documentation says that an enabled plugin may list skill directories in openclaw.plugin.json. Those plugin skills load at the same low-precedence tier as extra directories. A workspace or managed skill with the same name can override them. This is a useful distribution contract: the plugin can provide a safe default operating method while an operator retains a higher-precedence local policy.

Consider a ticketing plugin. The plugin owns OAuth, target discovery, pagination, write calls, and structured results. Its bundled skill can require a project key, reproduce the team’s issue template, demand a preview before creation, and define what counts as an idempotent retry. The runtime remains reusable across teams; the instruction layer remains replaceable by the team that owns the workflow.

The browser pair on the inspected host follows that architecture even though the skill arrived through an extra directory rather than the plugin manifest itself. The observable result is the same: runtime capability and operating method are separate records. That is healthier than hiding both behind one opaque “integration enabled” switch.

Validation: a matrix that survives edge cases

The matrix deliberately separates “external service” from the decision. An authenticated local CLI may make a skill sufficient for a SaaS workflow. A local-only provider may require a plugin. The owner is determined by what OpenClaw must load and what the model must learn, not by the destination of a packet.

Migration is usually smaller than a rewrite

When a skill outgrows its tools, keep the operating contract and move only the missing capability into a plugin. Preserve the decision rules, review language, and failure handling in SKILL.md; replace direct command assumptions with the newly registered tool. The workflow remains readable while authentication and transport gain a proper runtime owner.

When a plugin has become a maze of team-specific branching, move those choices in the other direction. Keep the general tool surface in the plugin. Extract labels, approval thresholds, target selection, and output conventions into a skill with higher-precedence local overrides. Runtime code should not need a release because one team renamed a queue.

Two receipts should survive either migration:

• Capability receipt: the active Gateway shows the expected plugin contract or registered surface.
• Behavior receipt: the intended agent sees the expected skill, meets its requirements, and produces the required evidence on a representative task.

Keeping those receipts separate is the practical answer to OpenClaw skills vs plugins. Use a skill for the method. Use a plugin for loaded capability. Use both when the capability deserves an operating method—but preserve the seam, because that seam is where diagnosis, override, and security review remain possible.

Sources for this decision

• OpenClaw Skills — loading precedence, gating, agent visibility, security boundaries, and plugin-provided skills.
• OpenClaw Plugins — install sources, native and compatible formats, policy, restart behavior, and runtime verification.
• Building OpenClaw plugins — current manifest, runtime registration, tool contracts, and package proof.
• OpenClaw plugin manifest — static capability ownership and the relative skills directory contract.

For the instruction side in greater depth, the companion OpenClaw skills guide covers triggers, dependency gates, per-agent visibility, Workshop review, and ClawHub verification. This memo stays at the ownership boundary: decide what must be taught, what must be loaded, and how to prove each one separately.