OpenClaw Skills: How to Create Them and Restrict Agent Tools

OpenClaw Skills: How to Create Them and Restrict Agent Tools

To create a skill in OpenClaw, write short instructions for a single role (when to use it, steps, limits and answer format). Then, separately, configure a small list of allowed tools for the agent that will run it. The skill guides behavior, but the tool and permission configuration is what enforces the limit. That is why the two need to be designed together and tested before the agent touches real data.

Key takeaways

• A skill describes how to perform a role. The allowed tool list defines what the agent can actually do. One does not replace the other.
• Start with a narrow role that has a defined beginning, end and human owner, not a generic agent.
• Grant tools on a default-deny basis: everything closed, and open only what the role requires, read-only first whenever possible.
• Actions that change something in the world (sending a message, editing a record, moving money) need human approval and logging.
• Test the skill with normal cases, edge cases and attempts to push it off course before widening its use.

What a skill is and what it does not do

In OpenClaw, a skill is a reusable package of instructions that the agent loads when a task calls for it. Usually it is a folder with an instructions file in markdown and, if needed, supporting material. The exact format, accepted fields and location of skills vary with the installed version, so confirm everything in the project's official documentation before standardizing across the company. If you already know the concept from Claude Code, the idea is similar, and it is described in Claude Code Skills: How to Create Them for Your Team.

The point that causes the most trouble in deployments is confusing instruction with control. Writing in the skill that the agent must never delete a record is guidance. It helps, but a language model can fail to follow an instruction, especially when faced with malicious text arriving in a message or a document. Real control happens when the tool that deletes records is simply not available to that agent.

Think of the two layers this way:

• Skill: context, procedure, tone, decision criteria, when to ask for human help.
• Tools and permissions: what the agent can read, write, run and access, and what requires approval.

This separation shows up in good LLM security practice. The OWASP Top 10 for LLM applications covers, for example, excessive agency: giving the agent more functions, permissions or autonomy than the task requires.

How to create a skill for a specific role, step by step

The outline below works for any role. The mental example is a repetitive, well-bounded task, such as triaging quote requests or answering status questions.

• Define the role in one sentence. Example: classify incoming quote requests and prepare a draft reply for review. If the sentence needs an and, you probably have two skills.
• Write the trigger. Say when the skill should be used and when it should not. A good name and description help the agent pick the right skill among several.
• List the expected inputs. What information arrives (customer text, order number, attachment) and what to do if something is missing.
• Describe the steps in order. Clear verbs, one step per line, with the exit criterion for each.
• Define the limits. What the agent does not do, which data it must not repeat in the reply, which topics always go to a person.
• Define the output format. Draft, structured fields, summary for the owner. Predictable output makes review and measurement easier.
• Write the human handoff point. Who receives it, with what summary, in which channel.
• Include two or three short examples of input and expected output, including one case where the correct response is to refuse or escalate.

On the writing itself, the same care applies as for any agent instruction: be direct, avoid contradictory rules, and prefer a few clear rules to many vague ones. The guide How to Write Instructions for an AI Support Agent: 5 Blocks covers this kind of writing for customer support.

A common mistake is turning the skill into the entire company manual. Long skills use up context, dilute the model's attention and bury important rules. If the role needs an extensive policy, keep that document separate and have the skill point to it, making clear when to consult it.

How do you choose a short list of allowed tools?

The useful question is not which tools the agent could use, but what the minimum is to do the job. This is the principle of least privilege, described in authorization material such as the OWASP authorization guidance, and it applies to agents just as it does to people.

A simple decision guide for each candidate tool:

• Does the role fail without it? If not, leave it out.
• Does it only read, or does it also write? If it writes, start with a read-only version and add writing after the pilot.
• Does it reach more data than needed? If so, restrict by folder, table, account or field instead of opening the whole system.
• Does it have an external effect (sends a message, creates a charge, publishes)? If so, require human approval per action.
• Is it reversible? Irreversible actions stay out of automatic reach.
• Does it run commands or access the network openly? In general, keep it off for business roles unless there is isolation and a justification.

Once you decide, write the final list somewhere the team can review it. A mental table with three columns helps: tool, reason it exists, type of access. If no one can fill in the reason, the tool goes.

It is also worth looking after the quality of the tools themselves. Anthropic publishes guidance on writing tools for agents, with emphasis on clear names, precise descriptions and lean responses. Ambiguous tools lead to wrong calls even when the skill is good. To understand the mechanism behind those calls, see What Is Function Calling in LLMs? How AI Uses Tools and APIs.

If a tool comes from a third-party MCP server, the review has to be even more careful, because you inherit whatever it exposes. MCP is an open protocol for connecting agents to tools and data, and installing a server without auditing it is a common way to widen access without noticing. The article How to Audit an MCP Server Before Installing It at Your Company walks through that review.

Illustrative scenario: triaging quote requests

This is an illustrative scenario, unrelated to any real company. Imagine a small services company that receives quote requests by email and WhatsApp. The sales lead wants the agent to read the request, identify the type of service, check whether information is missing and prepare a draft reply.

The skill, in plain language, would say:

• Use this skill when a new quote request arrives. Do not use it for complaints, billing or questions about orders already in progress.
• Identify the requested service, the location and the desired deadline. If any of these is missing, list the necessary questions in the draft.
• Never state prices, discounts or firm deadlines. Prices are set by a person.
• Deliver a draft and a three-line summary for the owner. Send nothing to the customer.
• If the request mentions sensitive data, a safety emergency or a legal threat, hand off to a person immediately.

The allowed tool list would be short:

• Read access to the inbox or the conversation where the request arrived.
• Read-only lookup of the service catalog.
• Creation of an internal draft for review, without sending.
• Recording the decision in a log.

Left out: sending directly to the customer, editing records, access to finance, running commands and open web browsing. Once the pilot shows the drafts are good, the company can consider allowing sending with human approval per message, never all at once.

Notice that the skill and the tools say the same thing in different ways. The skill states that the agent sends nothing. The configuration ensures it cannot send. If one of the two layers fails, the other still protects.

How to test the skill and the restrictions before release

Test on two fronts: the skill's behavior and the tool barrier.

For behavior, build a small set of anonymized real cases or invented ones:

• Typical cases, which the skill should handle well.
• Incomplete cases, where information is missing.
• Out-of-scope cases, where the right move is to refuse or hand off.
• Ambiguous cases, where a human would also hesitate.

For the barrier, deliberately try what the skill forbids. Ask the agent, by message, to send something, query another system or ignore the rules. Include malicious text embedded in an attachment or an email, which is called indirect prompt injection. OWASP maintains a prompt injection prevention guide that helps build these tests. The expected result is not the agent politely declining, but the tool not existing for it. Record any case where the agent achieved something it should not have, and fix it in the configuration, not only in the skill text.

Then check the logs. Each run should show which skill was used, which tools were called, with what parameters and what was decided. Without that, there is nothing to audit or improve. Further reading on validation layers is in Guardrails for AI Agents: Input, Output and Action Controls.

If the agent runs on a gateway reachable over the network, the exposure of the gateway itself belongs in the review too. The OpenClaw Gateway Security Checklist covers that point, and the OpenClaw for Business: A Production Implementation Guide shows the production context.

In Brazil, remember that if the role touches personal data of customers or employees, the LGPD applies: a clear purpose, minimizing what the agent sees and attention to what stays in the logs. For official guidance, the ANPD website is the starting point. Legal questions should go to the company's legal team, not into the skill.

How the map, limit, pilot and hand over method applies

The method we use to deploy agents follows four moves, and each one corresponds to a decision about skills and tools.

• Map: describe the current process and the baseline, meaning how the task is done today, by whom and with what volume of exceptions. Without this, the skill is a guess. The article on How to Map Business Processes Before Applying AI: A Step-by-Step Guide details this stage.
• Limit: reduce data and actions to the minimum. This is where the short tool list is born, with reading before writing and human approval for external effects.
• Pilot: run a real flow, with logs and a success metric agreed before starting. The skill is adjusted based on what the records show.
• Hand over: deliver the operation with documentation, owners and a criterion for deciding whether to expand, adjust or stop.

None of this requires promising a result. The goal is that, at the end of the pilot, the company has evidence to decide, not an impression.

Review checklist before activation

Use this list as the exit gate of the pilot:

• The role fits in one sentence and has a named human owner.
• The skill says when to use it, when not to, what to deliver and who to hand off to.
• Each enabled tool has a written reason and an access type (read or write).
• Actions with external effects require human approval.
• Secrets and keys are not inside the skill text and are not accessible to the agent beyond what is necessary.
• Tests included attempts to push the agent off course and prompt injection.
• Logs record skill, tool, parameters and decision, and there is a defined retention period.
• There is a simple way to switch the skill off or revoke a tool.

Frequently asked questions

Do I need to write code to create a skill in OpenClaw?

In general, the core of a skill is structured text with instructions, not code. Code only comes in if the skill depends on its own scripts or integrations, and in that case the security review needs to be deeper. Confirm the accepted format in the documentation for the version you use.

Does the skill alone guarantee the agent will not do something forbidden?

No. The skill guides the model, but the model can make mistakes or be misled by malicious text. The guarantee comes from restricting the tools, permissions and credentials available, so that the forbidden action is out of the agent's reach.

How many tools should an agent have?

There is no right number, only a criterion: just the ones the role cannot do without. If you cannot explain in one sentence why a tool is enabled, remove it and reassess after the pilot. Short lists also make it easier for the agent to choose the right tool.

When does it make sense to allow write actions, such as sending messages?

After a pilot with reviewed drafts, consistent logs and an agreed quality metric. Even then, start with human approval per action. For outbound WhatsApp messages, also consider the template and consent rules described in WhatsApp Outbound Messages: Templates, Opt-In and Best Practices.

Sources

• OWASP: Top 10 for LLM Applications
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• Anthropic: Writing effective tools for agents