write-release-notes

发布说明

项目负责制定规则：版本如何递增、已发布的清单存放在哪里、描述文件是什么样的，以及其中的文案如何撰写。本技能只负责收集上下文，并确保遵循这些规则，而不是自行猜测。

查找说明

首先查找项目的发布文案编写说明——先看 releases/WRITING.md，再看 AGENTS.md、CONTRIBUTING.md 或 releases/README.md 指向的文件。如果没有相关说明，请停止并询问发布说明的位置；不要自行编造版本方案或文件格式。

如果用户没有指定发布渠道，而说明中定义了多个渠道，请询问用户选择哪个。只问一个问题，并将各个渠道列为选项。

收集上下文

除非用户已在请求中提供，否则自行收集以下信息：

1. 各个渠道已发布的内容，从说明所述的清单存放位置获取。按照说明绕过缓存（通常使用新的查询参数）。清单缺失表示该渠道从未发布；网络故障则不代表发布历史为空——应报告故障，不要将其视为空历史。
2. 当前工作树：git rev-parse --short HEAD、今天的 UTC 日期（date -u +%Y%m%d）以及 git status --porcelain。如果工作树有未提交的更改，应向用户说明，因为基于该工作树构建的版本将与 HEAD 不一致。
3. 自该渠道已发布的提交以来的变更——运行 git log <published>..HEAD，并着眼于用户能感知到的变化来阅读。面向变更日志读者撰写的提交消息（参见 commit-changes）是主要依据；如果仍有不明确之处，再查看差异。

撰写发布说明

严格遵循有关版本选择、文件名和格式的说明。如果发布者提供了确切的描述文件路径或版本，请原样使用，即使日期或清单已发生变化也不例外。

面向安装此版本的用户撰写：说明他们现在能做什么、修复了哪些他们可能遇到的问题，以及有哪些变化会影响他们。省略内部重构，除非它们会带来可观察到的变化。

完成

展示所选文件和版本，并简要说明选择该版本的理由。除非用户要求，否则不要提交；绝不要发布、打标签或推送——发布应由用户完成。