关于 changelog
用于为 PR 中的重要提交创建变更日志条目的技能。它会排除仅涉及文档等不纳入记录的改动，并按项目的文件命名和类型约定编写简洁、面向用户的条目。
主要功能
- 01筛选重要变更
- 02选择变更日志类型
- 03按 PR 命名文件
- 04撰写面向用户的说明
- 05标记破坏性变更
适用场景
- 01记录面向用户的新功能
- 02记录行为变更或缺陷修复
- 03为一个 PR 添加多条记录
- 04标记破坏性变更
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/changelog确认已加载。
详细介绍
为此 PR 中的重要提交创建变更日志文件。PR 编号作为参数提供。
说明
-
以下情况跳过变更日志：仅涉及文档、内部重构、仅涉及测试、CI 更改，以及修复尚未发布的更改（未发布更改的条目已涵盖这些内容；如果修复会改变条目的描述，则更新该条目）。
-
首先，检查当前分支相对于 main 包含哪些提交：
git log main..HEAD --oneline -
对每项重要更改，在
changelog/文件夹中按以下格式创建变更日志文件： 允许的类型：added、changed、deprecated、removed、fixed、security、performance、other{PR_NUMBER}.added.md- 用于新功能{PR_NUMBER}.added.2.md、{PR_NUMBER}.added.3.md- 用于同一类型的其他条目{PR_NUMBER}.changed.md- 用于现有功能的更改{PR_NUMBER}.fixed.md- 用于错误修复{PR_NUMBER}.deprecated.md- 用于弃用内容{PR_NUMBER}.removed.md- 用于移除的功能{PR_NUMBER}.security.md- 用于安全修复{PR_NUMBER}.performance.md- 用于性能改进{PR_NUMBER}.other.md- 用于其他更改
-
每个变更日志文件至少应包含一行以
-开头的主要描述，清楚说明更改内容。不要换行。 -
如果更改较复杂，可以在主要描述后添加缩进的补充说明或代码示例。
-
对于破坏性更改，使用 ⚠️ 表情符号作为前缀。
-
首先从面向用户的角度描述更改。 先说明框架用户会注意到的内容：新 API、行为变化、新参数、修复的用户可能遇到的错误等。实现细节（内部重构、底层接线方式）可以作为补充背景，但如果更改对用户可见，绝不能只写实现细节。
好的示例（先描述用户可感知的变化，再补充实现细节）：
- Turn completion instructions now persist correctly across full context updates when using `system_instruction`. Previously they were injected as a context system message, which caused warning spam and didn't survive context updates.不好的示例（只描述实现细节，没有从用户角度说明）：
- Fixed turn completion instructions being injected as a context system message instead of using `system_instruction`.请自问：“如果我是基于 Pipecat 进行开发的开发者，会注意到哪些变化？” 从这里开始写。
-
写好条目后，运行
/prose-review changelog/，并修复它指出的问题。
示例
对于包含一项新功能和一项错误修复的 PR #3519：
changelog/3519.added.md：
- Added `SomeNewFeature` for doing something useful.
changelog/3519.fixed.md：
- Fixed an issue where something was not working correctly in some user-visible scenario. The root cause was an internal implementation detail.