Installing a skill from ClawHub is one of the lowest-risk things you can do to extend OpenClaw. Skills are text files, not code, so they cannot crash the gateway or corrupt your config. But a poorly chosen skill can conflict with your existing behavioral instructions, activate on requests it should not touch, override carefully tuned SOUL.md rules, or introduce prompt injection risks if it came from an unvetted source. Installing a skill correctly means more than copying a file into the skills directory and hoping for the best. This article covers the complete safe installation process: vetting before the install command runs, the actual installation mechanics, verification steps after install, conflict checking against your existing setup, and what to do when things do not behave as expected after a skill goes live.
TL;DR
- Read the SKILL.md before installing. The install command does not review the instructions for you.
- Run the security audit scanner and review every flagged line manually before activating.
- Test with a specific trigger phrase after install to confirm the skill activates correctly.
- Check for conflicts with SOUL.md, AGENTS.md, and existing skills before going live.
Throughout this article you will see indented blocks like the ones below. Each one is a command you can paste directly into your OpenClaw chat. Your agent will run it and report back. You do not need to open a terminal or edit any files manually.
Before you install: read the skill first
The most important step in a safe skill installation happens before the install command ever runs. Open the skill’s SKILL.md on ClawHub or its linked GitHub repository and read it cover to cover. The entire file. You are looking for several specific things, and what you find determines whether the install proceeds or stops here.
First, does the description tag accurately describe when the skill should activate? A description that is too broad, like “use this skill when the user asks anything about technology,” will cause the skill to fire on requests that have nothing to do with what the skill is designed for. A description that is too narrow means the skill will rarely activate even on the exact requests it was built for. Either way, the mismatch between the description and the actual use case is something you need to identify and resolve before the skill enters your workspace, not after.
Second, do the skill’s instructions conflict with anything in your SOUL.md or AGENTS.md? A skill that instructs the agent to respond in a specific tone that contradicts SOUL.md, or that tells the agent to skip a step that AGENTS.md requires, creates behavioral ambiguity that produces inconsistent results and is hard to debug.
Third, do the instructions reference tools or capabilities that you actually have? A skill that requires a tool registered by a plugin you have not installed will instruct the agent to call a tool that does not exist, producing errors or hallucinated results.
Before I install a ClawHub skill, help me evaluate it. I will paste the contents of the SKILL.md below. Read it and tell me: (1) Is the description tag specific enough to avoid firing on unrelated requests? (2) Does anything in the instructions conflict with the behavioral rules in my SOUL.md or AGENTS.md? (3) Does the skill reference any tools or capabilities that are not available in my current setup? Flag any concern, even minor ones.
Run the security audit before activating
OpenClaw includes a built-in security audit tool specifically for skills. It is a Python scanner that reads SKILL.md files and looks for patterns associated with supply chain risks: instructions that would cause the agent to exfiltrate data, commands designed to make the agent take unexpected external network actions, instructions that attempt to override safety rules or ignore prior instructions, and similar red flags. The scanner produces false positives, which is why every flagged line requires manual review in context rather than automatic rejection of the skill. But it consistently catches real problems that a casual read misses, and running it takes under 30 seconds.
Run the security audit on the skill I am about to install. The SKILL.md is located at [path to the skill directory]/SKILL.md. Run:
python3 skills/agents-skill-security-audit/audit.py [skill-name]/SKILL.md. Show me the complete audit output. Do not summarize. I need to see every flagged line.
When reviewing the audit output, evaluate each flag in context. Common false positives include:
- Web search instructions flagged as “external network access” when the skill legitimately uses web_search or web_fetch as part of its workflow
- File read instructions flagged as “filesystem access” when reading a config file is a legitimate and expected part of the skill’s task
- exec tool usage flagged as “arbitrary command execution” when the skill uses exec for a specific, documented diagnostic purpose
Genuine concerns to take seriously:
- Instructions to send data to a specific external URL that is not disclosed in the skill’s description
- Instructions to read openclaw.json or other config files and include the contents in a response
- Instructions to override SOUL.md or AGENTS.md rules, or to ignore previous instructions
- Instructions that change the agent’s behavior for all requests rather than only for the skill’s specific task type
- Any instruction that asks the agent to conceal what it is doing from the user
The security audit flagged these lines: [paste flagged lines]. For each one: (1) Read the flagged line in the context of the surrounding instructions, (2) Determine whether this is a false positive (the flagged action is a legitimate part of the skill’s stated purpose) or a genuine concern (the flagged action is not necessary for the skill’s stated purpose or is not disclosed), (3) Tell me your verdict: safe, false positive, or genuine concern that blocks install.
Installing the skill
ClawHub skills are installed with the npx clawhub install [skill-slug] command. This downloads the skill package to your workspace skills directory and sets up the SKILL.md file in the correct location for the agent to find it. Unlike plugin installation, skill installation requires no gateway restart and does not modify openclaw.json in any way. The skill is available to the agent immediately after the install command completes, on the very next request that matches its description.
Install the ClawHub skill with slug [skill-slug]. Run:
npx clawhub install [skill-slug]. After the install completes, confirm: (1) What directory was the skill installed to? (2) What is the full path to the SKILL.md file? (3) Is the skill now visible in the available skills list? Do not activate or test the skill yet. Just confirm the install completed and the file is where it should be.
If npx clawhub install is not available in your environment, or if the skill you want is distributed as a direct download or GitHub repository rather than a formal ClawHub package, you can install it manually. Manual installation is sometimes preferable because it gives you complete control over exactly what is placed in your workspace with no install script running on your server:
Install this skill manually. Create a new directory at
skills/[skill-name]/. Write the SKILL.md content I provide into that directory. After writing the file, confirm: (1) The directory exists, (2) The SKILL.md file is present and contains the expected content, (3) The file is readable. Do not test yet.
Verifying the installation
After the install command completes, verify the skill is correctly in place before using it for anything that matters. Verification takes less than two minutes and catches the most common installation problems before they produce confusing behavior. There are three things to check: confirm the file exists at the expected path, confirm the skill appears in the available skills list, and confirm the description tag is correctly formatted so the agent can parse it reliably.
Verify the skill installation. (1) Read the SKILL.md at its installed location and show me the name field, description field, and location field. (2) List all skills currently in my workspace and confirm this skill appears in the list. (3) Check that the description tag is correctly formatted with opening and closing tags. If any of these checks fail, tell me exactly what is wrong before we proceed to testing.
One of the most common installation problems is the skill directory landing at the wrong path. OpenClaw scans specific directory locations when building its skills list, and a SKILL.md that ends up outside those locations is simply invisible to the agent. It will never be selected regardless of how well its description matches an incoming request. Verify that the actual installed path matches exactly what the skill’s location field specifies.
Check that the skill’s location field matches where it was actually installed. Read the SKILL.md and show me the location field value. Then confirm that the file exists at exactly that path. If the file is at a different path than the location field specifies, that needs to be corrected before the skill will work reliably.
Checking for conflicts with existing setup
Before testing the skill in live use, check whether its instructions conflict with your existing setup. Three types of conflicts are common and worth checking explicitly before they cause problems in production.
Description overlap with existing skills. If the new skill’s description tag covers the same territory as an existing skill, the agent may activate either one on matching requests, producing inconsistent behavior. Check whether any currently installed skill has a description that overlaps with the new skill’s trigger conditions.
Check for description overlap between the newly installed skill and my existing skills. Read the new skill’s description tag. Then list all other installed skills and their descriptions. Are there any existing skills whose description covers similar request types? If yes, which requests might trigger either skill, and what is the likely behavior when both descriptions match?
Instruction conflicts with SOUL.md or AGENTS.md. Skill instructions operate alongside the agent’s core operating files. If a skill says “always respond formally” but SOUL.md says “be direct and conversational,” the agent faces a conflict it has to resolve in-context, and the resolution may not be what you want.
Check the newly installed skill for conflicts with my SOUL.md and AGENTS.md. Read the skill’s instruction body. Then read SOUL.md and AGENTS.md. Are there any direct contradictions? Are there any cases where the skill instructs behavior that SOUL.md or AGENTS.md prohibits? List every conflict found, even minor ones, so I can decide whether to resolve them before using the skill.
Tool availability mismatches. A skill that references a tool the agent does not have will fail silently or produce hallucinated output. Check that every tool the skill references in its instructions is actually available.
Check whether all tools referenced in the new skill’s instructions are available in my current setup. Read the skill’s SKILL.md and identify every tool it instructs the agent to use (e.g., web_search, exec, memory_recall, any tool registered by a plugin). Then confirm each tool is currently available. Flag any tool the skill requires that is not available and tell me what would happen if the agent tried to follow those instructions without that tool.
Testing the skill after installation
With installation verified and conflicts checked, test the skill with a deliberate, intentional trigger before it sees any real use. Do not rely on organic production traffic to discover whether the skill works correctly. Send a specific test request that should activate the skill based on its description, explicitly verify that the skill is being selected, and evaluate whether the agent’s response follows the skill’s instructions in the way you intended when you reviewed them.
Test the newly installed skill. I am going to send a request that should trigger it. Before you respond to the request itself, tell me: (1) Is this skill activating for this request? (2) Which skill are you reading? (3) What are the first three instructions in the skill? Then respond to the request following the skill’s instructions. This confirms the skill is loading, matching, and being followed correctly.
If the skill does not activate on a request that clearly should trigger it, the most likely cause is a description mismatch rather than an installation problem. The agent compares the vocabulary and intent of incoming requests against the skill’s description tag. If the phrasing of your real-world requests does not match the vocabulary and framing used in the description closely enough, the skill will not be selected no matter how well it would handle the request if it were selected.
The skill is not activating on requests where I expect it to. Read the skill’s description tag carefully. Based on the description, give me three example request phrasings that should reliably trigger this skill. Then tell me why the request I sent did not match. Is this a description problem (the description is too narrow or uses different vocabulary than real requests), or is the skill genuinely not appropriate for the request I sent?
If the skill activates but the agent does not follow its instructions correctly, the issue is in the instruction body. Ambiguous instructions, instructions that assume context not present in the request, or instructions that conflict with higher-priority rules in SOUL.md or AGENTS.md all produce this symptom.
The skill is activating but the response does not match what the instructions describe. Read the skill instructions again carefully. Then tell me: which specific instruction in the skill is not being followed? Is it because the instruction is ambiguous, because it conflicts with a rule in SOUL.md or AGENTS.md that takes priority, or because the instruction references a step the agent cannot complete with available tools? Identify the specific instruction and the specific reason it is not being followed.
Editing an installed skill
One of the most operationally useful properties of skills is that they are plain text files you can edit directly at any time. If an installed skill from ClawHub has a description that fires too broadly, contains instructions that conflict with your specific setup, references tools you do not have, or has steps that do not match how your workflow actually runs, you can open the SKILL.md and edit it directly to fix any of those issues. There is no build process, no deployment pipeline, and no gateway restart required. The edited version takes effect on the very next request that activates the skill.
I want to edit the installed skill to fix [specific problem]. Read the current SKILL.md at its installed location. Show me the section that needs to change. Then propose the specific edit: what the current text says, what it should say instead, and why that change fixes the problem without introducing new issues. Do not apply the edit yet. I want to review the proposed change first.
When editing a skill from ClawHub, track your changes so you know what you modified from the original. If the skill is updated by its author in the future and you reinstall it, your edits will be overwritten. Keeping a note of your customizations means you can reapply them after an update.
Apply the edit to the skill SKILL.md. After applying, create a comment block at the top of the file noting: the date of the edit, what was changed, and why. This documents our customizations so they can be reapplied if the skill is ever reinstalled or updated. Then confirm the file was saved correctly.
Removing a skill that is not working out
If an installed skill turns out to be less useful than expected, conflicts with your setup in ways that are not worth the effort to resolve, or simply does not handle its task type the way you need, removing it is completely straightforward. Delete the skill directory (or just the SKILL.md file inside it if you want to keep the empty directory for a replacement), and the skill is immediately and permanently unavailable to the agent with no other changes required.
Remove the skill [skill-name] from my installation. (1) Show me where the skill directory is currently located. (2) Confirm there are no other files in that directory I should preserve before deletion. (3) Delete the SKILL.md file. (4) Confirm the skill no longer appears in the available skills list. No gateway restart needed. Just confirm the file is gone.
The ClawHub security context: why vetting matters
In March 2026, security researchers publicly identified over 800 malicious packages in the ClawHub marketplace, with approximately 42,000 OpenClaw instances confirmed as exposed at the time of disclosure. The majority of those malicious packages were plugins rather than skills, because plugins can run arbitrary code and have far greater capacity for damage at the system level. But the incident established a fact that every ClawHub user should internalize: listings are operator-submitted and go live without guaranteed independent security review. They cannot be assumed safe simply because they appear in the marketplace.
Skills carry a lower risk profile than plugins because they cannot run code. But skills can still contain prompt injection payloads, instructions designed to exfiltrate data through the agent’s messaging tools, behavioral overrides that weaken security posture, and instructions that cause the agent to act outside its intended scope. The March 2026 incident did not produce documented cases of malicious skills because the researchers were focused on code-level plugins. That does not mean skill-based supply chain attacks are impossible or unexploited.
Help me understand the risk profile of this specific skill before I install it. The skill is: [name/description]. Looking at its instructions: (1) Does it instruct the agent to make any external network calls beyond what is needed for its stated purpose? (2) Does it instruct the agent to read any files outside the normal workspace? (3) Does it modify how the agent handles all requests or only the specific task type it claims to address? (4) Does it include any instruction to ignore, override, or reinterpret instructions from other sources?
The three-review protocol in AGENTS.md (Ghost review, Gambit review, advisor review) is formally required for plugins. For skills, a lighter version applies: read the SKILL.md yourself, run the audit scanner, and resolve any flags before installing. The security audit scanner plus a careful manual read is the minimum bar. For skills that will touch sensitive workflows, communications channels, or credential-adjacent tasks, apply the full three-review protocol regardless.
Skill naming and organization in your workspace
As you install skills, keeping the workspace organized prevents the kind of confusion where two similarly named skills overlap, an old skill you thought you removed is still present, or a skill’s location field points to the wrong directory because it was manually placed somewhere non-standard.
A clean skill organization follows a consistent naming convention. Each skill gets a descriptive directory name that matches its function, not the ClawHub slug which may be generic or abbreviated. The SKILL.md inside follows the standard structure with accurate name, description, and location fields. Skills are documented in TOOLS.md or a separate SKILLS-INVENTORY.md so there is a human-readable reference of what is installed and what each skill does.
Show me the current state of my skills directory. List every directory under skills/, the name field from each SKILL.md, and whether the location field in each matches the actual file path. Flag any skills where the location field does not match, any skills with duplicate or overlapping names, and any directories in the skills folder that do not contain a SKILL.md.
After any new skill installation, update whatever inventory document you use. Whether that is TOOLS.md, MEMORY.md, or a dedicated skills list, keeping a current record prevents the situation where you cannot remember which skills are installed or what each one does without reading through individual SKILL.md files.
After installing the new skill, update my skills inventory. Add an entry for [skill-name] that includes: the skill’s purpose in one sentence, the request types it is designed to handle, the date it was installed, and the source (ClawHub slug or manual install). Write this entry to TOOLS.md under a Skills section, creating that section if it does not already exist.
Installing multiple skills in the same category
Some task categories benefit from multiple skills working together. A research workflow might have one skill for finding sources, another for synthesizing findings, and a third for formatting the final output. When multiple skills cover related territory, their descriptions must be sufficiently differentiated that the agent selects the right one for each step rather than triggering the wrong skill on the wrong request type.
I am installing multiple skills that handle related tasks. The skills are: [list skill names and their descriptions]. Check whether their descriptions are sufficiently differentiated. For each pair of skills: (1) Is there any request phrasing that could reasonably match both descriptions? (2) If a request matches both, which skill should take priority and why? (3) Is there a way to make each description more specific to avoid ambiguous cases?
When descriptions do overlap, the usual resolution is to make each one more specific and mutually exclusive. The skill for finding sources should describe requests that are explicitly in the research and sourcing phase. The skill for synthesis should describe requests explicitly about combining and analyzing gathered material. Overlap in the middle means either both activate and the agent has to reconcile conflicting instructions, or one consistently shadows the other and the shadowed skill never runs.
Keeping installed skills updated
Skills from ClawHub may be updated by their authors to fix bugs, add steps, improve descriptions, or address compatibility issues with new OpenClaw versions. Unlike plugins, you will not necessarily receive notification when a skill you use has been updated. Checking for skill updates is a manual process.
Check whether any of my installed ClawHub skills have available updates. For each skill installed from ClawHub (not manually created), show me: the current version or last-modified date of my installed SKILL.md, the ClawHub slug, and whether a newer version is available on ClawHub. If updates are available, show me a diff of what changed before I decide whether to update.
Before applying a skill update, read the changes just as you would read a new skill before initial install. An update from a legitimate author may be straightforwardly beneficial. An update to a previously legitimate skill from a compromised author account is the same risk as a malicious initial install. The review process does not get skipped for skill updates, and should never be skipped.
I want to update [skill-name] to the latest version from ClawHub. Before applying the update: (1) Show me a comparison of the current installed SKILL.md and the new version. What changed? (2) Are any of the changes in the instruction body rather than just formatting or description tweaks? (3) Do any of the instruction changes raise concerns from a security audit perspective? After I review, I will tell you whether to apply the update.
Writing your own skill vs. installing from ClawHub
ClawHub has skills for many common use cases, but the most precisely tuned skill for your specific setup is often one you write yourself. A skill you write knows your workspace structure, your naming conventions, your preferred output formats, and the specific tools you have installed. A ClawHub skill is written for a generic OpenClaw installation and may need significant editing to fit your context well.
The tradeoff is time. Writing a skill from scratch takes longer than installing and adjusting an existing one. The right starting point depends on how generic the task is. If ClawHub has a skill for weather queries, research workflows, or other generic tasks, installing and customizing it is faster. If you need a skill for a workflow specific to your business or a task category that has no ClawHub analog, writing from scratch is the cleaner path.
Help me decide whether to install a ClawHub skill or write my own for this task: [describe the task]. (1) Search ClawHub for existing skills that address this task type. (2) If something relevant exists, show me its description and tell me how much customization it would need for my setup. (3) If nothing relevant exists, outline what a custom skill would need: the description, the key instructions (numbered steps), and any tools it would rely on. Give me a recommendation: install and adapt, or write from scratch.
When you write a skill from scratch, the iterative approach works best. Write a minimal version with just the core description and two or three key instructions. Test it. Refine the description based on what requests do and do not trigger it. Add instructions based on what the agent does correctly by default and what needs explicit guidance. This gradual refinement produces better skills than trying to write a complete, comprehensive SKILL.md in a single pass.
Help me write a new custom skill for this task: [describe the task]. Start with a minimal version: a name, a specific description that activates on the right request types, a location path, and three to five core instructions that cover the essential steps. Do not try to be exhaustive. Write the minimal version, create the file, and we will test and refine from there.
Managing your skill inventory over time
A common pattern with OpenClaw operators is installing skills enthusiastically when first setting up, accumulating a collection over several months, and then finding that half the installed skills are never used, some descriptions overlap in confusing ways, and the overall skill set has drifted away from how the agent is actually used day to day. A periodic skill inventory review prevents this drift before it produces behavioral inconsistencies that are hard to trace to a root cause.
Run a skill inventory review. List every installed skill and for each one tell me: (1) What request type does this skill handle? (2) How recently has a request come in that would have triggered this skill? (3) Does this skill’s description overlap with any other skill’s description? (4) Are all the tools this skill references still available? Based on this inventory, identify any skills that are candidates for removal, consolidation, or description update.
A healthy skill set is one where every installed skill has a clear, non-overlapping purpose, all referenced tools are available, and the descriptions match how you actually phrase requests. Trim skills that no longer match your use patterns. Update descriptions that have drifted. Consolidate skills that address the same task in slightly different ways. The goal is a lean, purposeful skill inventory where every installed skill earns its place by actively and measurably improving the agent’s handling of real requests you actually send.
Frequently asked questions
Do I need to restart the gateway after installing a skill?
No. Skills are loaded from disk on demand, not cached at startup. The agent reads the SKILL.md file each time the skill is activated. Installing a new skill file makes it available immediately without any gateway restart. Removing a skill file makes it unavailable immediately for the same reason. This is one of the primary operational advantages of skills over plugins, which do require a gateway restart.
Can a skill from ClawHub update itself?
Only if the skill’s instructions tell the agent to update it, which would be a serious red flag in the security audit. Skills are passive text files. They do not have network access, cannot make requests on their own, and cannot modify themselves or any other file without the agent actively following an instruction to do so. A skill that contains instructions telling the agent to overwrite the SKILL.md, fetch updated instructions from an external URL, or modify any workspace file as part of its standard operation should not be installed.
A ClawHub skill says it requires a specific plugin to work. Should I install the plugin first?
Read the plugin requirements carefully before installing either. The skill’s documentation should specify which plugin it requires and what that plugin does. Before installing the plugin, run the full three-review protocol from AGENTS.md: Ghost manual review, Gambit review, and advisor review. Do not install the plugin simply because the skill requires it. If the plugin cannot pass the three-review protocol, do not install the skill either, since it cannot function without the plugin anyway.
The skill is activating on requests that have nothing to do with what it is designed for. How do I fix this?
The description tag in the SKILL.md is too broad. Edit the description to be more specific about exactly what types of requests should trigger the skill. A good description includes concrete examples of the request vocabulary that should match, the specific task category, and any explicit exclusions for request types that are similar but should not trigger the skill. After editing, test with several different request types to confirm the new description activates only on intended requests.
Can I install a skill without using the npx clawhub command?
Yes. A skill is just a directory with a SKILL.md file. You can create the directory manually, write the SKILL.md content yourself, or download a SKILL.md from a GitHub repository and place it in the skills directory. The install command is a convenience wrapper. Manual installation is sometimes preferable because it gives you direct control over exactly what gets installed and where, without any install script running code on your server.
How do I know which skills are currently active and which are installed but not being used?
There is no automatic usage tracking for skills. The way to determine which skills are being actively used is to check which skills are actually being selected during real conversations. Ask the agent to identify which skill it selected for a set of recent requests. Skills that are installed but never selected are either too narrowly described (no requests match), redundant (another skill matches first), or simply not relevant to your typical request types. These are candidates for removal or description adjustment to make them more useful.
Is it safe to install skills during active business hours or should I wait?
Skills are safe to install at any time. Unlike plugins, a skill installation cannot crash the gateway, take the agent offline, or affect any currently in-progress operations. The worst case of a bad skill install is that the next request matching the skill’s description gets an unhelpful response. If you are cautious, install during a low-traffic period so you can test and verify before the skill sees real production traffic, but there is no technical reason to avoid installing during active use.