最容易失败的 Skill，往往来自一句“帮我把这个流程自动化”。这句话没有说明输入从哪里来、允许做什么、怎样算成功，也没有定义失败后如何恢复。
自然语言可以降低创建门槛，但不能替代能力设计。
先判断任务是否已经稳定
适合创建 Skill 的任务通常具备四个条件：
- 已经手动或通过普通对话成功完成至少两次。
- 输入格式大致稳定，例如固定列名的 CSV 或固定结构的会议记录。
- 产物可以明确验收，例如文件数量、字段、格式或返回状态。
- 失败可以停下并重试，不会立即造成不可逆损失。
“每次都要重新讨论目标”的任务不适合封装。先把方法跑稳，再谈复用。
写一份最小能力合同
创建前先用六行描述 Skill：
名称：会议行动项整理
输入：当前工作区中的会议记录文件
动作：提取结论、负责人、截止日期和未决事项
输出：output/action-items.xlsx，不覆盖原文件
权限：仅读取输入文件，只写入 output 目录
失败：缺少负责人或日期时标记“待确认”，不得自行补造这份合同比“做一个会议 Skill”更重要。它会成为生成、测试和以后排错的共同标准。
用自然语言发起创建
打开“技能”，选择“添加技能”中的创建入口，把能力合同连同样本说明交给 WorkBuddy。建议使用 Plan，让它先解释准备采用的步骤、依赖与权限，再确认生成。
可以继续补充：
- 支持和不支持的文件类型。
- 输出文件名冲突时的处理方式。
- 是否允许网络访问或第三方 API。
- 日志需要记录哪些字段。
- 哪些错误必须终止任务。
不要在第一版同时支持十种输入和多个外部系统。先让最小路径可靠。
检查生成结果，而不是只看成功提示
创建完成后，在已安装技能中查看说明和相关文件。重点确认：
- 描述是否与能力合同一致。
- 是否申请了未声明的目录或系统权限。
- 是否依赖额外命令、包或 API Key。
- 是否会把输入发送到第三方。
- 是否存在删除、覆盖和递归遍历。
- 错误是否会被明确返回。
不理解的脚本不要直接在真实资料上运行。可以让 WorkBuddy 解释每个关键步骤，但最终仍要以实际行为测试。
建立三层测试
正常样本
准备一份字段完整、格式标准的输入，验证能否生成预期产物。
边界样本
准备缺少日期、空内容、重复记录或特殊字符，检查它是否按合同标记问题，而不是编造信息。
失败样本
使用不支持的文件或只读目录，确认 Skill 会停止并说明原因，不会悄悄跳过后仍报告成功。
每次测试都在独立工作区运行，并检查右侧边栏的“变更”。
用验收表判断是否可以复用
| 检查项 | 通过标准 |
|---|---|
| 输入范围 | 只读取指定样本 |
| 输出位置 | 只写入约定目录 |
| 内容质量 | 关键字段完整，未知信息不编造 |
| 错误处理 | 可识别、可解释、可重试 |
| 权限 | 没有超出能力合同 |
| 重复运行 | 不误覆盖，结果可预测 |
至少连续通过三次，再把它用于更大的真实任务。
迭代时一次只改一个变量
如果结果不稳定，不要同时换模型、改提示词、增权限和换样本。固定其他条件，一次只调整一个部分，才能知道改动是否有效。
建议在名称或说明中记录版本，例如 meeting-actions v0.1。每次扩大输入范围、增加外部连接或改变写入逻辑，都重新跑三层测试。
什么时候停止使用
- 任务流程已经变化，原合同不再成立。
- 依赖或第三方 API 长期不可用。
- 权限范围无法缩小到合理水平。
- 输出错误很难被验收发现。
- 维护成本高于每次直接执行。
Skill 不是越多越好。少量透明、稳定、有人维护的能力，比一长串无人敢调用的工具更有价值。
完成检查
- 任务在创建前已经手动跑通。
- Skill 有明确的输入、输出、权限和失败规则。
- 正常、边界、失败样本都已测试。
- 生成内容和实际变更已检查。
- 你知道何时更新、关闭或卸载它。