约定提交发布 PR 与变更日志生成器

要解决的具体问题

当团队采用 Conventional Commits 之后，提交历史里其实已经携带了足够的版本语义：fix: 应当触发 patch，feat: 应当触发 minor，BREAKING CHANGE 则应当触发 major。问题在于，这些语义只存在于提交记录里，并不会自己变成版本号、CHANGELOG.md 的段落，或者一个等待人工审核的发布 PR。

手工维护这三样东西很容易漂移：忘记升版本号、changelog 分类口径不一致、把若干无关提交塞进同一个版本。release-please 要处理的正是「从已合并提交到结构化发布物」这一段机械但易错的工作。

核心能力与关键步骤

这个技能把 release-please 包装成 Agent 可以直接调用的发布管理流程，关键步骤大致是：

1. 读取已合并进主分支的 Conventional Commits；
2. 按提交类型（fix、feat、BREAKING CHANGE 等）推导版本升级幅度，生成新版本号；
3. 创建结构化的发布 PR，内容包含版本号变更与变更日志更新；
4. 更新语言相关的元数据文件，例如 Node.js 仓库的 package.json、Python 仓库的 pyproject.toml；
5. 更新 CHANGELOG.md，把对应提交按类型归入相应版本的段落；
6. 产物停留在 PR 阶段等待人工审核与合并，而不是自动发布。

需要明确的是，这是一个发布管理工作流，既不是通用的包管理工具，也不是 CI 任务清单。

适用边界与注意点

• 前提是仓库使用 GitHub 且提交遵循 Conventional Commits，否则无法推导出可靠的版本语义。
• 支持的语言/生态有明确的可发布单元（releasable unit）配置：

- node：带有 package.json 与 CHANGELOG.md 的 Node.js 仓库；
- python：带有 pyproject.toml、<project>/__init__.py、CHANGELOG.md，可选 setup.py 或 setup.cfg 的 Python 仓库。

• docs 前缀在 Java 和 Python 中是可发布单元的前缀。
• 部分语言有自己的可发布单元配置，需要按语言分别确认。
• 示例中提到了空提交的情形，说明处理历史时边界情况需要被纳入考虑。
• 最终产出是待审核的发布 PR，是否真正发布仍由人决定。