Menú
从 PR 和 commit 生成版本发布说明。 当准备发版、需要从 PR 与 commit 汇总发布说明时使用。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
标记任务为阻塞状态并记录原因。 当任务因外部阻塞无法推进、需要挂起并记录原因时使用。
取消不再需要的任务并转移。 当某个任务不再需要、应从 active 工作中撤下时使用。
关闭 Code Scanning 告警并记录理由。 当某条 Code Scanning 告警已处理或需按理由关闭时使用。
关闭 Dependabot 安全告警并记录理由。 当某条 Dependabot 安全告警已处理或需按理由关闭时使用。
标记任务完成并归档。 当任务工作已完成并验证、需要收尾归档时使用。
从平台 Issue 评论还原本地任务文件。 当本地任务文件缺失、需要从平台 Issue 评论还原时使用。
| name | create-release-note |
| description | 从 PR 和 commit 生成版本发布说明。 当准备发版、需要从 PR 与 commit 汇总发布说明时使用。 |
基于已合并的 PR 和提交，为指定版本生成全面的发布说明。
从参数中提取：
<version>：当前发布版本（必需），格式 X.Y.Z<prev-version>：上一版本（可选），如未提供则自动检测当前标签：v<version>
上一标签（如未指定）：
git tag --sort=-v:refname
查找 v<version> 之前最近的标签。
验证标签存在：
git rev-parse v<version>
git rev-parse v<prev-version>
获取最近多条已发布的 Release Note 作为格式参考，并参考预定义的完整分类清单：
执行前先读取 .agents/rules/release-commands.md。
# Part A：按 `.agents/rules/release-commands.md` 的 release 查询命令逐条获取最近 3 条 Release 的 body
Part B：完整分类清单
🆕 Feature✨ Enhancement✅ Bugfix📚 Documentation用途：
获取标签之间的日期范围，然后查询已合并的 PR：
# 获取标签日期
git log v<prev-version> --format=%aI -1
git log v<version> --format=%aI -1
# 获取范围内已合并的 PR（按 `.agents/rules/release-commands.md` 的 merged PR 查询命令执行）
同时收集没有 PR 的直接提交：
git log v<prev-version>..v<version> --format="%H %s" --no-merges
从 commit Co-authored-by trailer 中收集协作贡献者：
git log v<prev-version>..v<version> \
--no-merges \
--format='%(trailers:key=Co-authored-by,valueonly,unfold)' \
| grep -v '^$' | sort | uniq -c | sort -rn
输出每行一个 Name <email>（uniq -c 给出该身份在范围内作为 co-author 的 commit 数）。
从每个 PR body 中提取关联的 Issue：
Closes #N、Fixes #N、Resolves #N（不区分大小写）按 .agents/rules/release-commands.md 的关联 Issue 查询命令读取。
按类型（从 PR 标题的 Conventional Commit 前缀）：
feat、perf、refactor、依赖升级 -> Enhancementfix -> Bugfixdocs -> Documentation（如少于 3 项则合并到 Enhancement）按模块（从 PR 标题 scope、标签或文件路径）：
[module] 或 Conventional scope feat(module): 推断模块优先使用步骤 3 中获取的历史格式风格，并确保覆盖步骤 3 列出的所有分类。 如果存在历史发布说明，严格沿用其章节结构、标题风格（含 emoji）、条目格式和双语布局。
如果没有历史发布说明，使用以下默认格式化为 Markdown：
## {模块/平台名称}
### Enhancement
- [{scope}] Description by @author in [#N](url)
### Bugfix
- [{scope}] Description by @author in [#N](url)
## Contributors
@contributor1, @contributor2, @contributor3, @reporter1 (reported #N)
格式规则：
- [scope] Description by @author in [#N](url)in [#Issue](url) and [#PR](url)type(scope): 前缀，首字母大写.agents/rules/release-commands.md 中已合并 PR 查询规则git log ... --format='%(trailers:key=Co-authored-by,valueonly,unfold)'.agents/rules/release-commands.md 返回）该人的 PR 数 + 该人作为 co-author 的 commit 数（同一身份跨来源合并计数）@login 映射：
Co-authored-by 原始格式为 Name <email>，需要推断对应的 platform @login.agents/rules/release-commands.md 中的平台 no-reply 邮箱规则时，按该规则推导小写 loginClaude Opus 4.6 (1M context) → @claude、Codex → @codex、Gemini → @gemini）Claude 和 @claude 拆成两个条目Claude 与 Claude Opus 4.6 (1M context) 都映射到 @claude 时，应先合并为同一个贡献者dependabot[bot]）@{Name 首 token 小写}，并在 Contributors 段落下追加 <!-- TODO(reviewer): 确认 {原始 Name <email>} 的 platform login -->@login 为键author.login@login (reported #N) 格式展示；同一 reporter 报告多个 Issue 时使用 @login (reported #N1, #N2)向用户展示生成的发布说明。
询问：
9.1 把生成的 notes 写入工作树之外的临时文件，避免在仓库残留未提交产物（不要写入 .agents/workspace/ 或任何受版本控制的目录）：
NOTES_FILE="$(mktemp "${TMPDIR:-/tmp}/agent-infra-release-notes.XXXXXX")"
把 notes 内容写入 $NOTES_FILE。
9.2 按 .agents/rules/release-commands.md 的「发布 Release notes」命令执行（命令中的 {notes-file} 用 $NOTES_FILE；写入已由 release 工作流自动创建/发布的 Release，不存在时兜底创建）。
9.3 无论发布成功或失败，都删除临时文件：
rm -f "$NOTES_FILE"
输出：
Release notes 已更新。
- URL: {release-url}
- Version: v{version}
- Status: Published
发布说明已写入该 Release。如需进一步调整，可在上面的 URL 直接编辑。
v{version} 的 Release 由 release 工作流自动创建并发布（给 Homebrew bottle 提供上传落点）；本技能往该 Release 写入/刷新 notesmktemp）并在发布后删除，禁止写入仓库目录