如何编写自己的第一个 Skill：从重复任务提炼方法
以会议纪要为示例，整理触发条件、输入、执行步骤、边界与验收标准，写出可以测试和继续维护的 Skill。
写自己的第一个 Skill，可以从已经重复做过的工作开始。不要先追求覆盖所有任务。选择一个边界清楚、结果能检查的场景，把真实有效的步骤整理下来，再用另一份输入验证。
选一个稳定的小任务
例如“把会议记录整理成决策、行动项与待确认问题”。它有明确输入，也有可以对照原文检查的输出。相比“成为办公专家”，这样的目标更容易写清楚适用条件和失败情况。
收集一次做得好的结果和一次出现问题的结果。前者帮助确定结构，后者帮助补齐边界：记录没有负责人时怎么办，原文冲突时怎么标记，是否应该保留不同意见。
按目标客户端的格式保存
如果编写开放格式的 Agent Skill，先按 Agent Skills 官方规范准备目录与 SKILL.md，写清名称和描述。脚本、参考材料与模板可以分别组织，具体能力仍取决于目标客户端。
客户下载包、企业内部工作流和不同客户端的安装约定可能不同。为哪种环境编写，就按哪种环境的说明测试，不要只因为文件名相似就假定完全兼容。
把方法写成可以执行的要求
- 读取用户指定的会议记录，确认会议名称与日期。
- 提取明确决定，保留原文依据。
- 整理行动项；没有负责人或截止时间时标记待确认。
- 把冲突表述和未决问题放入单独区域。
- 对照原文检查是否增加了没有依据的人名、日期或承诺。
这些是会议场景的示例要求，不是已经安装的 Skill。编写时使用明确动作，少写“输出高质量内容”这样的模糊要求。需要调用脚本，就写明输入、输出和失败提示。
附上小样例与验收标准
用虚构资料展示期望结构，并说明哪些信息不能推断。比如“下周安排评审”没有负责人和具体日期，结果里应保留待确认，而不是主动指定某个人。
验收至少检查关键字段、原文对应关系和缺失信息处理。样例不是为了让 AI 复制固定内容，而是说明怎样判断结果是否符合方法。
用不同输入测试，再改方法
准备清晰记录、缺信息记录和存在冲突的记录各一份。观察方法能否保持输出结构，是否会错误补全，是否遗漏重要决定。出错后先定位哪个要求没有写清，再修改指令或脚本。
对于执行脚本，实际运行并打开输出文件。没有跑过的环境不要写成已支持。测试结果与版本一起记录，方便以后判断改动有没有影响已有任务。
让维护保持简单
主说明保留最重要的流程，长参考资料单独放置并明确引用。每次修改说明原因，保留一份成功输入输出。想进一步区分固定方法与临时需求，可以阅读 Skill 和提示词的区别；执行遇到问题时，使用 排查指南逐项定位。