先固化高频动作
- 第三次重复出现的动作，就应该开始考虑 skill 化。
- 优先固化开工检查、问题分诊、插件上线前检查这类稳定场景。
- 先解决重复劳动，再谈更大的自动化野心。
Skills
把 OpenClaw 里的重复动作固化成 Skills / SOP
真正有用的 skill 不是大而全的万能脑，而是把高频、重复、判断路径稳定的动作固化下来，让自己和团队都能复用。
DepthPilot Summary
这节课真正教你的，是把重复判断沉淀成团队资产
Skill 的价值不在于写一个万能脑，而在于把经常发生、判断路径稳定、验收标准明确的动作沉淀下来。DepthPilot 在这里强调的是：先选对要固化的动作，再把核心流程、长说明、脚本逻辑拆开，最后用触发语和固定输出去验证 skill 是否真的稳定。
再拆清结构
- SKILL.md 负责短流程，references 负责长说明，scripts 负责确定性逻辑。
- 写得越像一篇长文章，越难复用和维护。
- 好的 skill 不是内容多，而是边界清晰。
最后用稳定输出验收
- 如果 skill 每次触发结果差异很大，说明它还不够收敛。
- 验收要看它是否稳定命中、稳定输出、稳定指导下一步。
- 真正的交付物是一项团队可复用的操作能力，不是一个看起来聪明的文件夹。
优先固化哪类动作
项目开工检查：doctor、channel probe、search provider、pairing 状态。
每日巡检：最新失败任务、插件健康、权限错误、积压队列。
插件上线前检查：版本、Gateway 重启、最小回归验证。
群聊或工单分诊：先补上下文，再决定是用工具、skill 还是人工接管。
怎么写才不会又长又废
核心流程写进 `SKILL.md`，长说明放到 `references/`。
能脚本化的内容放到 `scripts/`，不要把固定逻辑全塞进自然语言。
一个 skill 只解决一个稳定场景，不要一开始就写大而全的总控。
写完之后怎么验收
至少准备 2 到 3 个真实触发语，看 skill 是否能稳定命中。
要求 skill 产出固定结构结果，例如 checklist、问题摘要或下一步建议。
如果结果波动很大，就说明 skill 还不够窄，应该再切小。
Starter Template
项目里已经放了一个可直接复用的 `SKILL.md` 模板和启动检查清单。先从一个“项目开工检查” skill 开始，比追求完美更有价值。