Agent Skills
返回列表
💻

变更日志自动化

开发编程 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @org-02qudk26/changelog-automation。

技能介绍

问题从哪来

版本发布若仍靠人工翻 git log 写变更说明，常见结果是：提交信息风格不一、Breaking Change 漏标、发布说明与语义化版本对不上号。团队一旦引入约定式提交（Conventional Commits）或 semver，缺的是一套可重复执行的生成与校验流程，而不是再写一份「提交规范」文档。

技能在做什么

本技能围绕变更日志格式、版本策略与发布说明工作流给出可落地的模式与工具选型思路，核心步骤包括：

  • 选定 changelog 格式（如 Keep a Changelog）与 semver bump 规则
  • 通过提交约定或标签规则强制执行格式，避免「规范只存在于 README」
  • 配置生成工具，把标签区间或提交范围转成发布说明
  • 对生成结果做准确性、完整性、措辞检查，必要时对照 resources/implementation-playbook.md 中的模板与示例

适用边界

  • 适合：已有或计划建立发布节奏、希望提交历史能直接驱动 release notes 的项目
  • 不适合：没有版本管理、只做一次性手动说明，或提交历史不可用/不可信时，自动化收益有限
  • 安全：发布说明会对外可见，需避免写入密钥、内部-only 路径或未脱敏的运维细节

使用场景

  • 已有按 Git 标签发版的项目，需要配置工具在每次发版时从提交区间生成 Keep a Changelog 式说明
  • 团队准备启用约定式提交，要在首次自动化发布前定好 semver 升级规则与标签策略
  • 在 CI 流水线里增加 changelog 生成与发布说明步骤，发版前核对 Breaking Change 是否漏标
  • 多个仓库提交格式混乱，需先统一提交约定或标签规则，再接入自动生成 release notes

适合人员

  • 维护 semver 发版节奏、希望用提交历史生成对外 release notes 的开源或内部项目负责人
  • 在 CI/CD 中搭建发版流水线，需要选型 changelog 工具并设计生成后校验步骤的平台/DevOps 工程师
  • 推动多服务仓库统一 Conventional Commits、再接入变更日志自动化的技术负责人或架构师
  • 刚引入语义化版本、想把「人工翻 git log 写说明」改成可重复检查流程的发布协调人