先从一个比喻说起
你可以把 OpenClaw 想象成一位非常聪明的新员工——脑子好用，什么都能学，但刚来公司的第一天，他并不了解你们公司的具体流程和规范。
比如，你们公司有一套固定的"出差报销流程"：先填哪张表，再找谁签字，最后怎么提交。这些细节，OpenClaw 不可能提前知道。
这时候，Skill 就相当于一本"岗位操作手册"。
📌 Skill = 一份写给 OpenClaw 的、针对特定任务的操作指南。告诉它：遇到某类任务时，应该用什么工具、走什么流程、输出什么格式。
Skill 解决了什么问题？
OpenClaw 本身很强大，但它有个天然的局限：它不知道"你的上下文"。
举几个例子：
📄 处理 Word 文档 OpenClaw 知道 .docx 格式的原理，但不知道你的电脑环境里有哪些工具，应该用 pandoc 还是 python-docx，报错了怎么处理。
📊 生成 PPT 做幻灯片有很多方式，Skill 可以规定必须用某个特定库、走特定步骤，保证每次输出质量稳定一致。
🎨 前端设计 设计风格千变万化，Skill 可以规定设计原则、字体规范、颜色系统，让 OpenClaw 输出符合你审美的界面。
有了 Skill，OpenClaw 每次遇到相关任务，就能自动查阅这份手册，按照规定好的方式去做，不用每次靠用户反复说明。
Skill 长什么样？
一个 Skill 本质上是一个文件夹，里面最核心的是一个叫 SKILL.md 的文件：
my-skill/├── SKILL.md ← 核心文件，必须有├── scripts/ ← 可执行的脚本（可选）├── references/ ← 参考文档（可选）└── assets/ ← 模板、字体等资源（可选）
SKILL.md 分为两个部分：
🏷️ 头部信息（frontmatter） 用 --- 包裹，写 Skill 的名字和触发描述。这是 OpenClaw 判断"什么时候该用这个 Skill"的依据。
📝 正文内容 用普通 Markdown 写的操作指南，告诉 OpenClaw 具体怎么做这件事。
举个例子：写一个"日报生成"Skill
假设你每天要根据当天的工作记录，生成一份统一格式的日报。我们来写一个 Skill 来自动化这件事。
目标：用户说"帮我写今天的日报"，OpenClaw 能按照规定的格式自动生成。
第一步：创建文件 daily-report/SKILL.md
---name: daily-reportdescription: 当用户提到"写日报"、"生成日报"、"今天的工作总结"时使用此 Skill。 帮助用户将工作记录整理成统一格式的日报。---
# 日报生成 Skill#
# 日报格式要求每份日报必须包含以下四个部分，用 Markdown 输出：##
# 格式模板**【日期】** YYYY年MM月DD日**【今日完成】**- （用简洁的一句话描述每项完成的工作）**【遇到的问题】**- （如没有问题，写"无"）**【明日计划】**- （列出明天要做的事）#
# 注意事项- 语言简洁，每条不超过 30 字- 完成事项要量化（如"完成了3个接口开发"而非"开发了接口"）- 如果用户没有提供明日计划，根据上下文合理推断- 输出后询问用户是否需要调整
就这么简单！一个能用的 Skill 只需要：一个触发描述 + 一份操作指南。
实际使用效果：
用户： 帮我写今天的日报，今天完成了首页改版，修复了两个 bug，下午开了个产品对齐会。
OpenClaw （调用 Skill 后）： 自动生成符合模板格式的日报，完成事项量化，结尾询问是否调整。
Skill 是怎么被触发的？
OpenClaw 在处理每个请求时，会先扫描所有可用 Skill 的名字和描述，判断当前任务是否需要调用某个 Skill。
⚠️ 关键点：description 字段越准确，触发越可靠。 最好明确写出"当用户说了什么、做了什么事"才触发，而不是用模糊的说法。
✅ 好的描述： 「当用户提到"写日报"、"今日总结"、"工作记录整理"时触发，帮助生成规范日报格式」
❌ 差的描述： 「日报相关的任务」——太模糊，OpenClaw 不知道什么情况下该调用。
总结
-
Skill 是写给 OpenClaw 的"操作手册"，告诉它遇到特定任务时怎么做。
-
核心文件是
SKILL.md，包含触发描述和操作指南两部分。 -
触发描述（description）越具体，OpenClaw 调用越准确可靠。
-
可以附带脚本、模板等资源，处理更复杂的任务。
-
写好一个 Skill，以后同类任务就不用反复说明，省时省力。
如果你有想自动化的重复性工作，不妨试试写一个属于你自己的 Skill
