用途：本技能用于在 kimi-code 仓库中生成 Changesets，即面向用户的变更日志条目。唯一对外发布的包是 CLI：@moonshot-ai/kimi-code；其余 @moonshot-ai/* 包（sdk、kosong、kaos、oauth、telemetry 等）均为内部包。
是否要写：若用户无法感知该变更，则不写 changeset。仅文档或测试变更、核心/服务端内部包变更（架构、协议、重构、配置/日志/传输机制）不写，除非修复用户关心的 bug。用户可感知的新功能或行为变化要写；内部包变更若修复对用户有用的 bug 或改变 CLI 输出/行为，也要写，并列出 @moonshot-ai/kimi-code。不确定时先询问。
写什么：在 .changeset/ 下创建短 kebab-case 文件名，frontmatter 指定包与级别，正文用一句面向用户的英文，只说明改了什么，去掉解释原因、收益或机制的后缀。默认值翻转或移除旧行为时，要说明用户失去的行为，并给出逃生开关（如 set [watch] enabled = true 或 KIMI_CODE_WATCH=1）；没有开关就明说旧行为不可用。新功能写明是什么加一行用法；实验性功能还要说明如何启用（flag、配置键或环境变量）。不要出现文件名、类名、函数名、PR 编号，不要用 refactor、optimize、improve 等模糊词，不要用真实内部标识，用 example.com、YOUR_API_KEY 之类占位符。一个 changeset 只写一个逻辑变更，无关变更拆成多个文件。内部包自身 changelog 可写得技术化。
Bump 级别：patch 用于 bug 修复、小改进、已有功能的配置新增，拿不准时用它；minor 用于用户此前无法做到的新能力（新 slash 命令、子命令、模式）；major 永不写，若认为符合要停下询问用户，没有明确批准则回退到 minor，仍不清楚则 patch。
写哪个包：内部变更进入 CLI 打包且用户可感知，列 @moonshot-ai/kimi-code；不进入 CLI 或不可感知则不写，写了也只列该内部包。不要在一个 frontmatter 中混合被 .changeset/config.json 忽略的包与未忽略的包。pi-tui 例外：仅 pi-tui 的变更列 @moonshot-ai/pi-tui；若同一变更对 CLI 用户也可见，另写一个 CLI changeset（两个文件，不混合）。kimi-inspect 与 vis 包从不出现在 changeset 中。
工作流：先运行 git status / git diff --name-only 查看实际变更的包；按上述规则判断，无需写则停止；选定包与 bump 级别并写一句话；提交前把 changeset 文本给请求者确认；不理解变更不要猜，先完成清楚的部分，再列出不清楚处并询问是否可深入代码。发布前检查累积的 .changeset/ 条目，删除非面向用户的条目——发布 PR 会基于 main 上的 .changeset/ 重新生成，删除文件即移除对应 changelog 条目，不影响已发布代码。