在实践中，一般通过skill创建期，来协助创建skill，但是高质量的Skill的标准需要我们自己来把关。可以通过以下5个流程创建Skill：
- 判断任务值不值得封装
- 提取专家决策和常见反模式
- 吧指令写得简介且约束合适
- 配齐模板，参考资料和脚本
- 用真实任务反复验证执行效果
完整的skill结构：
skill-name/
├── SKILL.md # 必需 入口文件：frontmatter + body
├── agents/
│ └── openai.yaml # 推荐 技能的"名片"
├── scripts/ # 可选 可执行脚本
├── references/ # 可选 参考文档
└── assets/ # 可选 产出物模板
一、值不值得做成skill
- 任务里有没有"专家直觉"
如果一个任务里，熟手和新手 的差距主要体现在，边界判断、风险识别、优先级取舍，那它就是适合做成skill。
2.任务是不是足够复杂
如果一个任务一句Prompt就能说清，或者三步以内就能完成，通常没必要专门做成skill，skill不是越多越好。他有维护成本，要写说明、配资源、做测试、反复迭代。
3.任务会不会反复出现
skill 的价值在于复用。如果某项工作或流程，反复的被用到，就有必要沉淀成skill，长期收益通常很高。
当同一个任务，同时具备以上三个特征时，建议投入做成skill。
二、skill该写什么
确定任务需要做成skill后，按照下面步骤来提取skill需要做什么。
- 提取决策树
高质量 的skill应该高数Agent：
- 什么条件下走方案A
- 什么条件下切到方案B
- 什么情况下应该停止、降级或补充信息
2.提取反模式和不要做的事情
在工程里，反模式往往非常重要，比如
- 不要把来源不明的内容当事实写进输出
- 不要再高风险操作里直接执行修改，应该先生成计划再验证
- 不要为了把结果写完整，擅自编造确实信息
- 提取模板和示例
如果任务对输出结构要求很高，那么可以使用模板来描述；如果任务对表达风格，组织方式要求很高，那就使用示例来说明。
三、写清楚指令
skill指令里面的指令要符合三个原则：
- 简介
skill不是独占上下文的，还要和system prompt、对话历史、其他技能信息一起共享窗口，所以每一句话要值回它的token成本。
原则很简单：模型本来就知道的东西，不要重复教；只有任务特有的判断、约束、入口和资源导航，才值得写进skill。
2.自由度匹配
如果任务本身风险很高，比如批量改文件、数据库迁移、部署执行，那就应该给低自由度约束，必要时直接要求调用固定脚本。
如果任务本身需要分析、判断、归纳，比如代码审查、内容策划、方案评估，那就应该保留更高自由度，只给流程边界和质量标准。
3.渐进式披露
不要把所有细节都塞进SKILL.md，按照下面这些
原则组织：
- 主文件里只保留核心流程、触发条件和资源导航
- 详细规则放到reference/
- 需要确定性执行的动作放到scripts/
四、配好工具和资源
对一些具有标准流程的子任务，不要让大模型来踩，用工作流写清楚任务要求，用代码文件直接执行。
- 给Agent建立工作流
在复杂任务里，cheaclist非常中音号，因为任务链长了后，如果没有中间的进度和阶段目标，agent很容易漏步骤。 工作流示例如下：
- 抽取输入
- 运行检查
- 整理问题、修复后重新验证
- 在生成结果
- 把验证做成闭环
如果任务需要校验，Skill里不要只写"执行完即可"，写成反馈循环：运行验证器，读取结果，修复问题，再次运行验证器，通过后再进入下一步。
3.高风险操作先过计划，在执行
如果任务涉及大规模修改、高成本调用或者不可逆操作，最好再加一层"先验证计划"的前置检查。
- 脚本要对Agent友好
Skill如果有脚本，要符合以下要求：
- 输出最好结构化，优先JSON
- 错误信息里要带修复线索，不要只返回一个exit code
- 能降级就降级，不要一出错就崩。
- 尽量幂等，避免agent重复调用时把结果越做越乱。
五、用真实任务验证，再迭代skill
在应用实践中，推荐一套使用的迭代方式，
