用途：为采用 squash-merge 工作流的 monorepo 维护两份发布文档——面向产品负责人、运维和开发者的 RELEASE_NOTES.md（叙述式、收益优先、较详细），以及面向 API 集成方、审计和发布工程师的 CHANGELOG.md（简洁、事实性、关联 PR，遵循 Keep a Changelog 格式）。两者在同一次发布中基于同一批提交更新。
主要能力：识别变更边界（查看 main 上最后一次 squash-merge 提交与发布标签/日期）；列出 develop 自边界以来的提交（git log develop --oneline --no-merges --since="<date-of-last-release>"）；检查实际代码差异（git show --stat <sha>、git show --no-patch <sha>），关注新 API 端点、模型/schema、前端页面组件、基础设施（CDK 栈、配置）、测试文件与依赖变更；将变更归入标准化分类（New、Improved、Fixed、Changed、Security、Performance、Infrastructure、Dependencies、CI/CD、Docs，各带 emoji）；决定纳入或排除范围；把工程提交转写为用户收益表述。
使用方式：先完成边界识别与提交梳理，建立主变更清单；分类并过滤；先写 CHANGELOG.md（事实日志），再写 RELEASE_NOTES.md（将最大项提升为专题叙述，其余保留分类条目）；最后交叉核对两份文档一致。RELEASE_NOTES.md 新版本置于文件顶部，不改动历史段落，包含 Highlights、Feature spotlights、Bug fixes、Security、Performance、Breaking changes、Infrastructure、CI/CD、Dependency upgrades、Test coverage、Deployment notes 等章节。CHANGELOG.md 每条一行，尽量标注 (#NNN)，破坏性变更以 Breaking: 前缀并附迁移步骤，无条目的分类不渲染空标题。
适用场景：准备发布、更新已有发布条目、落地重要变更时。
限制与注意：不可盲信提交信息，需查看 diff；勿遗漏 Dependabot 批量升级与 CI/CD 工作流改动；勿在分类间重复叙述；勿让 changelog 与 release notes 脱节；确认 VERSION 文件与 README 徽章已通过 sync-version.sh 更新；无法确认的 PR 编号不要编造。资料未提供具体版本号、价格或平台信息。