用途：依据仓库实际证据（而非猜测）更新 docs/CHANGELOG.md，适用于新增最新发布条目、同步 GitHub Releases 文本、根据 git 历史或代码 diff 概括最新标签。
主要能力与默认约定：措辞简洁；除非用户明确要求补齐旧版本，只添加缺失的最新版本；优先使用 GitHub 来源（尤其 Releases 与标签元数据）；当发布只有少量明确条目时，跳过 Features / Improvements / Bug Fixes 标题。
使用步骤：
- 读取本地风格：打开 docs/CHANGELOG.md，匹配既有语气、项目符号风格、章节顺序和日期格式。
- 确定目标发布：读取根 package.json 版本并与变更日志首条比较；找到目标版本的前一个标签；若最新版本已有记录，则停止并报告无需更新。
- 收集证据，按优先级使用：GitHub release notes（GH_PAGER=cat gh release view v<version> --repo <owner>/<repo> --json tagName,name,publishedAt,body）、标签日期（git log -1 --format=%cs v<version>）、标签间提交历史（git --no-pager log --format='%h %s' --no-merges v<previous>..v<version>）、提交主题含糊时的 diff 范围（git --no-pager diff --name-only 与 git --no-pager diff --stat v<previous>..v<version>）；仅在用户可见变化仍不明确时直接阅读被改动文件。
- 提炼内容：包含用户可见功能、重要行为变更、提升可靠性/兼容性/开发者体验的缺陷修复、以及实质影响支持配置或上手流程的文档更新；除非明确要求，排除纯版本号提升、常规依赖更新、无可见影响的内部重构和机械格式噪音。
- 选择结构：1 至 3 个明确要点时直接写扁平条目；条目较多时使用简短标题如 Features、Improvements、Bug Fixes；不要为分类而分类。
- 撰写条目：只新增或更新被请求的版本条目；条目简短具体；复用邻近条目的项目术语；避免营销语言；不要逐字照搬嘈杂的 GitHub 发布文本。
- 验证：核对日期、版本号和标签边界；确保 Markdown 结构与邻近条目一致；确认未添加中间版本（除非被要求）。
完成检查：最新请求的版本有记录；措辞与周围变更日志一致；条目有 GitHub Releases、git 历史或代码 diff 支撑；低信号内部变更已略去。
限制：仅适用于具备 git 与 GitHub Releases 元数据的仓库；具体命令依赖版本标签命名（如 v<version>）与仓库路径参数，需按实际仓库调整。