Meta Skill Writer

帮我写个 skill。

Meta Skill Writer — 教你写 Skill 的 Skill

当用户提出「帮我写个 skill」时，按以下方法论创建。

核心原则

1. 渐进式加载优先

• description：只放触发条件，不放教程。让 Agent 一眼判断"这个场景该不该用我"
• SKILL.md：放操作流程和规则。描述工作步骤，不是原理说明
• references/：放长文档、API 说明、示例。只在执行中需要时才读
• scripts/：放确定性的机械操作。不要用脚本做"AI 文本处理"，要用脚本做"格式校验/API调用/文件操作"
• 不需要一开始就把所有内容塞进 prompt

2. 角色定位清晰

• 一个 skill 只做一类任务
• 如果发现 SKILL.md 里在写"如果是场景A就…如果是场景B就…"，说明该拆成两个 skill 了

3. 可测试

• 每个 skill 都应该能用 openclaw skills check 验证依赖
• 关键的脚本路径应该能在命令行独立测试

工作流

Step 1：需求分析

和用户确认三个问题：

1. 用户说什么话时应该触发这个 skill？ → 这就是 future description
2. 这个 skill 处理完交付什么？ → 确定输出（文件？消息？数据？）
3. 它的上游输入和下游依赖是什么？ → API？本地工具？用户手动提供？

Step 2：结构设计

按以下规则决定目录结构：

最小集（大部分场景够用）：

skill-name/
├── SKILL.md          # 必需。核心说明书
├── scripts/          # 可选。确定性脚本
├── references/       # 可选。长文档/参考
├── examples/         # 可选。输入输出样例
└── evals/            # 可选。最小评测集

什么时候加 scripts/：

• 有重复的格式化/校验/转换操作
• 有外部 API 调用
• 操作顺序固定、参数明确、不依赖 AI 判断

什么时候加 references/：

• API 文档太长，放 SKILL.md 里会冲淡流程
• 有 checklist、示例、模板需要按需读取
• 有业务背景知识但并非每次都需要

什么时候加 examples/：

• 输出格式复杂，Agent 容易跑偏
• 同一个任务有多种正确结果的风格，需要有参考对照
• 边界情况（如空输入、错误输入）的预期输出不好描述
• 好的做法：放 1-3 个好例子 + 1 个坏例子，标明为什么好/坏

什么时候加 evals/：

• skill 有核心路径不能倒退（改了某处不能把原本会做的做坏）
• 有多个脚本需要联动验证
• 需要定期回归检查的场景
• 最小评测集：5-10 个输入 + 预期输出，每次迭代后跑一遍

什么时候不该加：

• 不需要把"用 Python 的话要怎么装依赖"写成脚本（模型已经知道）
• 不需要把明显的常识性知识塞进 references
• examples/ 和 evals/ 不是越大越好——精选 3-5 个高质量样例胜过 20 个凑数的

Step 3：写 SKILL.md

使用 references/skill-template.md 作为起点，填充以下内容：

frontmatter 必须包含：

---
name: skill-name           # 简短，kebab-case
version: "1.0.0"           # 语义化版本
description: "一句话说明"   # 关键！Agent 靠这个判断是否触发
---

description 写作原则：

• 直接用用户会说的话 — 不用加"当用户说…时"这种包装。用户会说"帮我评估一下这个skill"，那 description 就写「帮我评估一下这个 skill」，一字不改
• 只写触发条件，不写功能描述
• 不写步骤细节（那些放正文）
• 中英文均可，但要一致

对比案例（multi-agent-skill-evaluator 的真实迭代）：

版本	description	问题
❌ v1.2	Multi-agent独立技能评估。对任意skill，通过3个隔离的子agent分别打分+评语，最后汇总报告	描述功能，不是触发条件
❌ v1.3	当你想评估某个 skill 能不能胜任它的工作...	好了点，但还有包装
✅ v1.4	帮我评估一下这个 skill	用户会说的话，一字不改

正文结构：

# Skill 名称 — 一句话用途
(如果超出 2 行，说明 skill 范围太大)

## 首次设置（如果没有就是空）
## 工作流（核心步骤，从触发到交付）
## 输出格式（如果有）
## 注意事项

正文写作原则：

• 写操作步骤，不是写原理
• 每步说明"做什么"和"为什么"，但不写"怎么实现"（模型知道怎么实现）
• 边界条件写清楚："什么情况下停下来问用户"、"什么情况下继续"
• 错误处理写清楚："失败了怎么办"、"预期时长"

Step 4：创建脚本（如果需要）

脚本的原则：

• 可独立测试：bash script.sh "input" 应该能跑通
• 参数化：不要硬编码路径，用参数或环境变量
• 有错误处理：检查输入、检查依赖、检查返回值
• 有回退策略：主方案失败时尝试次方案

Step 5：自检清单

完成前逐项自查：

• description 是否直接用用户会说的话？
• SKILL.md 把"怎么做"写清楚了吗？AI 按步骤执行会不会卡住？
• 有没有把常识性知识写进 skill（模型不需要教）？
• 是否有测试过关键脚本路径？
• 输出格式是否明确？
• 失败场景是否说明？
• 依赖是否在 metadata 中声明？
• examples/ 和 evals/ 如果加了，内容是否精选而非凑数？

Step 6：可选——让 skill-evaluator 评估

创建完成后，可以调用 multi-agent-skill-evaluator 对新建的 skill 进行质量评估，获取改进建议。

常见反模式

反模式	说明	正确做法
description 写成长文	触发条件模糊	直接用用户会说的话
SKILL.md 里塞 API 文档	冲淡操作流程	放 references/
一个 skill 做两件事	职责不清	拆成两个
用脚本做 AI 判断	脚本不应该依赖 AI	脚本只做确定性操作
缺少错误处理	失败时用户不知道怎么办	写明"如果 X 失败，告诉用户 Y"
硬编码路径/凭据	不可移植	用参数/环境变量