1. Skills机制概述
提起OpenClaw的Skills机制，不少人可能会把它想象成传统意义上的可执行插件。其实，它的内涵要更精妙一些。
简单说，Skills本质上是一套基于提示驱动的能力扩展机制。它并不是一个可以独立“跑”起来的程序模块，而是通过一份结构化描述文件（核心就是那个SKILL.md），去引导和约束大模型的具体行为。这就好比给一位经验丰富的专家一份详细的操作清单和决策流程图，告诉他“在什么情况下，应该用什么方法去解决问题”。
那么，Skills的核心价值到底在哪？它主要解决两个关键问题：第一，为Agent（智能体）提供决策依据，判断“何时该动用哪种能力”；第二，明确“具体如何调用底层的工具来执行”。这样一来，复杂的任务就能被清晰地模块化，并实现自动化拆解与执行。
从系统架构的视角往下看，OpenClaw的能力体系可以清晰地分为三层：
● Tool层：这是地基，提供最底层的可执行能力，比如执行一条系统命令、访问某个网页API。
● Skill层：这是中场指挥官，负责定义完成一个任务的具体流程，并制定调用哪些工具的策略。
● Plugin层：这是包装与分发层，负责对工具和技能进行封装，方便集成和管理。
2. Skills工作机制
Skills的运转，完全依赖于大模型的推理过程。整个流程可以清晰地划分为几个步骤：
- 用户提出需求（即输入Prompt）。
- 系统将所有已加载Skills的描述信息（都来自各自的SKILL.md文件）注入到系统提示（System Prompt）中。
- 大模型开始工作，它需要综合两方面信息进行推理：一是用户的具体请求，二是所有Skills的描述（包括功能说明和操作指令）。核心任务是判断：当前是否需要调用某个特定的Skill？
- 如果判断为“是”，模型就会遵循该Skill中预设的流程，去调用对应的底层Tool。
- Tool执行完毕并返回结果后，再由模型整合这些信息，生成最终的回答输出给用户。
因此，Skills的触发机制，其本质是“基于语义匹配的提示选择”，而非传统编程中那种直接的、显式的函数调用。这里有个细节需要注意：由于所有Skill的描述都会被注入到上下文中，这意味着每次推理都需要“携带”这些信息。所以，当系统中Skills数量变得非常多时，上下文长度和相应的Token消耗就会显著增加，这是在设计时需要权衡的一个点。
3. 自定义Skills的实现方式
3.1 基本结构
想要创建自己的Skill，首先得知道OpenClaw会从哪些地方寻找它们。系统主要检查三个位置：
● bundled skills：这是OpenClaw自带的“出厂技能包”，会随着npm安装包一起提供。
● ~/.openclaw/skills：这是本机用户目录下的共享skill文件夹，放在这里的技能可以被本机的所有项目访问。
● /skills：这是当前工作空间（workspace）下的专属skill目录。
这三个位置的加载优先级非常明确：
当前workspace下的/skills > 用户目录下的 ~/.openclaw/skills > 自带的bundled skills。
也就是说，你自己编写的skill，为了确保最高优先级和项目独立性，最常见、最推荐的做法就是放在当前项目workspace的skills/目录下。
一个典型的自定义Skill目录结构看起来是这样的：
.openclaw/workspace/skills/
└── my-skill/
├── SKILL.md # 核心描述文件
├── scripts/ # 相关脚本
├── references/ # 说明文档、数据schema、流程图等
└── assets/ # 模板文件、素材等