用 Codex 把发布说明流程变成可复用 Skill

整理发布说明时，你可能每次都要交代同一组要求：根据已合并 PR 摘要组织内容，区分新增与修复，省略没有用户可见变化的内部重构。如果已经有一段 Codex 对话产出了经过确认的成品，这段成功流程就可以成为创建 Skill 的起点。

本例要保存的是一套发布说明写作流程。输入是读者提供的 PR 摘要，预期产物是符合既定分类和措辞要求的草稿，核对依据是输入材料与已经认可的成品样例。

何时适合做成 Skill

先判断下一次是否还会复用同样的处理方法。发布范围和 PR 内容可以变化，但分类依据、事实取舍和输出要求应当能够复用。如果你能提供一个好结果，并解释哪些修改让它达到要求，就有了提炼技能的具体材料。

Skill 适合封装重复流程、团队经验，以及需要例子或辅助资源的操作方法。仓库中每次任务都应遵守的通用约定适合放进 AGENTS.md；编写发布说明这种按任务使用的流程，则可以独立成为技能。

创建前也应确认是否已有适合的插件。官方建议已有对应流程时优先复用。需要保留本项目特有的写作规则时，再从成功样例提炼自己的技能。

操作步骤

第一步：准备成功对话和成品。

留在那段已经完成发布说明的 Codex 对话中，明确指出最终认可的版本，以及形成这个版本的反馈。例如，哪些内容被归为修复，哪些内部调整被删除，哪些影响描述因为缺少依据而没有采用。

同时区分长期规则与当次事实。某次发布的版本名、日期和具体变更属于当次输入；分类原则、措辞要求和信息不足时的处理方式，才适合留给后续任务复用。

按照官方的工作流转技能示例，可以直接告诉创建工具“使用本次对话”，并补充希望未来产物遵循的标准。

第二步：给出明确的创建请求。

本例约定发布说明按“新增”“修复”组织，只收录用户可见变化。可以在成功对话中复制以下提示词，并按项目实际要求调整规则：

使用 $skill-creator 创建 release-notes 技能，放在当前仓库的 .agents/skills。  工作样例：使用本次对话，包括已经确认的发布说明、修改意见和最终采用的规则。 任务：根据我提供的已合并 PR 摘要，生成发布说明草稿。  需要保留的规则： - 按“新增”“修复”分类，没有内容的分类不强行填充。 - 只收录用户可见变化；未改变对外行为的内部重构不写入正文。 - 不根据 PR 标题补写未经材料确认的影响或兼容性结论。 - 信息不足时列出待确认项。  请明确输入、适用请求、处理步骤和输出标准，说明如何通过 $release-notes 调用。 保持 SKILL.md 简短，按需要添加参考资料、脚本或模板，并验证创建结果。 

这里的写作要求是这个示例技能的约定。其他项目可以采用不同分类，关键是把已经认可的判断依据讲清楚。

第三步：检查技能文件和描述。

本例的核心产物应是 .agents/skills/release-notes/SKILL.md。项目技能可以随仓库提交，让团队共同使用。

重点查看 name 和 description。描述应说明实际能力与适用请求，例如“根据用户提供的已合并 PR 摘要编写项目发布说明；在整理版本变更或起草发布说明时使用”。只写“帮助处理开发工作”，无法清楚表达它与其他任务的区别。

Codex 会先通过技能名称和描述发现能力，选中后再加载 SKILL.md，需要时才读取参考资料或运行脚本。因此，正文应保留核心流程；较长的写作规范可以放入 references/，输出模板可以放入 assets/。本例仅整理文本时，可以从一份自包含的 SKILL.md 开始。官方的定制说明介绍了这种按需加载方式。

验证方法

验证时分别检查文件组织、调用方式和输出内容。文件存在、描述完整之后，还要用新的输入核对它是否保留了原流程的判断标准。

先显式调用技能，使用下面这组示例材料：

请用 $release-notes，根据以下已合并 PR 摘要起草发布说明： - 新增：导出任务支持取消。 - 修复：筛选条件在翻页后丢失。 - 内部重构：调整导出模块，不改变对外行为。 

读者应检查以下项目：

• 是否使用了指定技能，并遵循其中的分类和写作要求。
• 前两项是否分别进入“新增”和“修复”，表达是否忠于输入。
• 第三项是否按本例规则从对外发布说明中省略。
• 是否擅自增加支持格式、清理机制或兼容性承诺等输入没有提供的事实。

再把输入替换为“优化导出”这类信息不足的摘要，检查是否列出需要确认的变化，而没有自行补出功能效果。

最后去掉 $release-notes，只提出“根据这些已合并 PR 摘要整理发布说明”，检查自然请求能否匹配技能描述。Codex 支持根据描述隐式选择技能，清晰描述有助于触发；这仍需要通过实际请求检查。也可以给出一条无关的代码解释请求，观察描述是否过宽，导致技能被用于不相关任务。

迭代维护

下一次发布说明出现偏差时，把具体输入、错误输出和期望处理方式一起反馈。例如，若内部重构被写成用户功能，可以这样要求：

请更新 $release-notes：刚才那项内部重构明确没有改变对外行为，应从发布说明中省略。保留这一取舍规则，并用刚才的材料重新检查输出。 

修改后应同时检查新问题与原有成功样例，确认新增规则解决了偏差，也保留了此前认可的行为。反馈涉及哪一条判断，就优先修正对应内容，避免把每次具体变更都积累成长期规则。

适用边界

这套方法适合已有成功样例、处理规则能够复用的工作流。如果每次任务的目标和评价标准都不同，应先通过具体任务厘清方法，再决定保存哪些部分。

本例始终以读者提供的 PR 摘要为输入，输出发布说明草稿。若以后要自动读取外部协作系统，还需要相应的连接能力；Skill 负责定义流程，外部系统访问由相关工具承担。维护时也应持续区分可复用规则与当次发布事实，避免旧版本内容进入新的发布说明。

更多技术细节，请点击文末“阅读原文”。