feat(commands): 优化 create-release-note 支持 x.y.0 合并路径并同步多 AI 工具

为 create-release-note 命令增加 x.y.0 版本的合并路径，可自动
合并前一 minor 系列已发布的 release notes 而无需重复计算。
将步骤结构拉平为同一层级（15 步），通过路径标记区分合并路径
（步骤 4-7）与常规路径（步骤 8-13）。
同时将命令同步到 Codex、Gemini、OpenCode 三个 AI 工具，
并在各工具的 release 命令中添加相关引用。

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: CodeCasterX

.claude/commands/create-release-note.md

@@ -10,6 +10,8 @@ usage: "/create-release-note <version> [prev-version]"
 
 自动从 PR、commit 和 Issue 中收集变更信息，按模块和类型分类，生成符合项目格式的 Release Notes。支持创建 GitHub Draft Release。
 
+对于 x.y.0 版本，支持合并前一 minor 系列的已发布 release notes，无需重复计算。
+
 ## 用法
 
 ```bash
@@ -21,6 +23,7 @@ usage: "/create-release-note <version> [prev-version]"
 ```bash
 /create-release-note 3.6.3           # 自动推断上一版本为 3.6.2
 /create-release-note 3.6.3 3.6.2     # 手动指定范围
+/create-release-note 3.7.0           # x.y.0 版本：合并 3.6.x 系列的所有 release notes
 ```
 
 ## 参数说明
@@ -32,6 +35,12 @@ usage: "/create-release-note <version> [prev-version]"
 
 ## 执行步骤
 
+步骤 1-3 为公共步骤，步骤 3 根据版本类型分流：
+- **合并路径**（PATCH == 0，如 `3.7.0`）：步骤 4-7 → 跳到步骤 14
+- **常规路径**（PATCH > 0，如 `3.6.3`）：步骤 8-13 → 继续步骤 14
+
+步骤 14-15 为公共步骤。
+
 ### 步骤 1：解析参数
 
 从 `$ARGUMENTS` 中提取参数。支持两种形式：
@@ -65,7 +74,60 @@ git rev-parse v<prev-version>
 
 如果任一 tag 不存在，报错退出：`错误：Tag v<version> 不存在，请确认 tag 已创建`
 
-### 步骤 3：收集合并的 PR
+### 步骤 3：判断版本类型并选择路径
+
+根据版本号的 PATCH 部分选择不同的生成路径：
+
+- **如果 PATCH == 0**（如 `3.7.0`）→ 走**合并路径**，从步骤 4 开始
+- **如果 PATCH > 0**（如 `3.6.3`）→ 走**常规路径**，从步骤 8 开始
+
+---
+
+### 合并路径（PATCH == 0，x.y.0 版本）
+
+### 步骤 4：查找前一 minor 系列的所有已发布 release
+
+```bash
+gh release list --limit 50 --json tagName,isDraft,isPrerelease
+```
+
+从结果中筛选满足以下条件的条目：
+- `tagName` 以 `vX.(Y-1).` 开头（例如版本 `3.7.0` 则筛选 `v3.6.` 开头）
+- `isDraft == false`
+- `isPrerelease == false`
+
+如果未找到任何已发布的 release，提示用户并回退到常规路径（步骤 8）。
+
+### 步骤 5：按版本号升序获取各 release body
+
+对步骤 4 筛选出的每个 release tag，按版本号升序获取其内容：
+
+```bash
+gh release view v<tag> --json body --jq .body
+```
+
+### 步骤 6：合并所有 release body
+
+将各版本的 release notes 合并为一份完整文档：
+
+1. **按版本顺序拼接**：按 `v3.6.1`、`v3.6.2`、`v3.6.3` ... 的顺序处理
+2. **同平台同类型条目合并**：将各版本中相同平台（如 FIT Function Platform）相同类型（如 Enhancement）的条目合并到一起
+3. **去重 Contributors**：合并所有 `❤️ Contributors` 段落中的贡献者，去重后按贡献量（出现次数）降序排列
+
+### 步骤 7：生成 Overview
+
+x.y.0 版本始终视为 Major release：
+
+1. **在顶部添加 `🌟 Overview` 总结段落**：AI 根据合并内容生成 2-3 句话概括整个 minor 系列的核心主题和亮点
+2. **每个平台添加 `🚀 Features Overview` 要点列表**：从该平台的 Enhancement 条目中提炼 3-5 个关键特性要点
+
+**完成后跳到步骤 14。**
+
+---
+
+### 常规路径（PATCH > 0）
+
+### 步骤 8：收集合并的 PR
 
 **主要数据源** — 获取两个 tag 之间的日期范围，然后用 `gh` CLI 查询合并的 PR：
 
@@ -91,7 +153,7 @@ git log v<prev-version>..v<version> --format="%H %s" --no-merges
 
 对比 PR 列表和 commit 列表，找出没有关联 PR 的 commit（这些 commit 也应纳入 release notes）。
 
-### 步骤 4：收集关联的 Issue
+### 步骤 9：收集关联的 Issue
 
 从每个 PR 的 body 中提取关联的 Issue：
 - 匹配模式：`Closes #N`、`Fixes #N`、`Resolves #N`（不区分大小写）
@@ -105,7 +167,7 @@ gh issue view <N> --json number,title,labels,url
 
 收集 Issue 详情用于丰富 release notes 的描述。
 
-### 步骤 5：分类 — 按模块分组
+### 步骤 10：分类 — 按模块分组
 
 根据以下**优先级**判断每个 PR/commit 所属模块：
 
@@ -125,7 +187,7 @@ gh issue view <N> --json number,title,labels,url
 | `waterflow`, `framework/waterflow/**` | **Waterflow Flow Scheduling Platform** |
 | `claude`, `.claude/`, `.ai-agents/`, AI 相关配置 | **🤖 AI Development Configuration** |
 
-### 步骤 6：分类 — 按类型分组
+### 步骤 11：分类 — 按类型分组
 
 根据 PR title 的 conventional commit type 分类：
 
@@ -135,17 +197,17 @@ gh issue view <N> --json number,title,labels,url
 | `fix` | ✅ Bugfix |
 | `docs` | 📚 Documentation（如果条目少于 3 个，并入 Enhancement） |
 
-### 步骤 7：判断发布级别
+### 步骤 12：判断发布级别
 
 根据变更数量和性质判断输出详细程度：
 
-- **Major release**（PATCH == 0 或合并 PR > 15 个）：
+- **Major release**（合并 PR > 15 个）：
   - 生成 `🌟 Overview` 总结段落（2-3 句话概括本次发布的核心主题）
   - 每个平台生成 `🚀 Features Overview` 要点列表
 - **Regular release**：
   - 直接列出 Enhancement / Bugfix 条目，不加 Overview
 
-### 步骤 8：生成 Release Notes
+### 步骤 13：生成 Release Notes
 
 按照项目已有格式输出 markdown。完整模板：
 
@@ -194,7 +256,11 @@ gh issue view <N> --json number,title,labels,url
 6. **空平台**: 如果某个平台没有任何变更，不输出该平台的章节
 7. **多作者**: 如果 PR 有多个 co-author，用 `and` 连接：`by @a and @b`
 
-### 步骤 9：展示并确认
+---
+
+### 公共步骤
+
+### 步骤 14：展示并确认
 
 将生成的 release notes **完整输出**给用户查看。
 
@@ -204,7 +270,7 @@ gh issue view <N> --json number,title,labels,url
 
 如果用户要求调整，根据反馈修改后重新输出。
 
-### 步骤 10：创建 Draft Release
+### 步骤 15：创建 Draft Release
 
 用户确认后，将 release notes 写入临时文件，然后创建 Draft Release：
 
@@ -237,6 +303,7 @@ gh release create v<version> \
 3. **Draft 模式**：创建的是草稿 Release，不会自动发布，需要人工审核后在 GitHub 上发布
 4. **PR 搜索范围**：基于日期范围搜索，可能包含少量超出范围的 PR，命令会尽力过滤
 5. **模块分类准确性**：自动分类基于 title/scope/文件路径推断，复杂 PR 可能需要人工调整
+6. **x.y.0 合并路径**：依赖前一 minor 系列的 release 已在 GitHub 上发布（非 Draft），如果没有已发布的 release 则回退到常规路径
 
 ## 错误处理
 
@@ -245,6 +312,7 @@ gh release create v<version> \
 - **`gh` CLI 未安装或未认证**：提示安装/认证方法
 - **无合并 PR**：提示版本范围内没有找到合并的 PR，建议检查 tag 和分支
 - **GitHub API 限流**：提示稍后重试
+- **x.y.0 无已发布 release**：提示前一 minor 系列没有已发布的 release，回退到常规路径
 
 ## 相关命令