用途
本技能用于审查一件依赖关系更新的 pull request，并将报告作为评论发布到该 pull request 上。它由 dependency-update 技能的指挥角色委派，对指定的一件 pull request 进行审查。用户不直接调用它。
更新对象可能是库，也可能是 Docker image、GitHub Actions 或运行时。文中命令和文件的示例以 Node.js 库给出，实际需根据更新对象及其生态的常识进行替换理解。
文件构成
技能目录下包含：
SKILL.md：本步骤书TEMPLATE.md：报告模板
执行前提
- 执行环境条件与 dependency-update 技能“执行环境确认”中的 model 条件相同。进入审查前需自行确认，若不满足，则不进行审查和报告发布，报告不满足的条件后结束。
- 无法向用户提问。判断不明的事项写入报告和汇报中。
- pull request 的位置、标签名称、阅读代码的位置、工作目录、报告语言均遵循指挥角色的指示。
- 只进行审查，以及评论发布和被指示时的标签添加。不修改代码、不 commit、不 push、不创建新的 pull request。需要修改时写入报告。
- 同一仓库中可能有其他 subagent 并行处理其他 pull request。不要更改指定工作目录之外的内容。
调查
按报告各节所需内容，依次调查以下事项。pull request 概要栏的说明可能有误，不能作为变更内容的依据。应以代码、diff 和官方文档为依据。引用外部文档时，需在报告中写明 URL。
更新对象概要
阅读 README 或官方网站文档，了解其实现目的和用途。
版本信息
调查变更前后的版本及各自发布日期。确认更新目标是否为最新版，其后是否还有 major version 更新。major version 更新时可能出现名称变更或仓库迁移。
变更范围
从 lock file 的 diff 中列出更新、新增、删除的包。即使数量多，也要无遗漏地列出主要变更对象。若包含与更新对象关系不明确的包变更，需注明。此时不要断定安全性和影响范围，而应作为后续章节需要确认的注意点。
例如 npm 的 package-lock.json，可从 pull request 的 diff 中提取 lock file 差异，并用 grep -C15 '<包名>' package-lock.json 确认个别包周边。
依赖关系
从 lock file 中列出依赖更新目标的其他包，以及更新目标所依赖的包。
使用位置与版本指定位置
按文件列出仓库中引用或指定更新目标及运行时的位置。不仅包括 import 语句和 require 语句，还包括配置文件、Dockerfile、CI 配置、开发环境配置等指定版本的位置。除按名称搜索外，也要按版本号搜索。其他章节读到的文件中若有版本指定，也纳入此列表。此列表将作为“代码与配置更新”中版本一致性确认的输入。
变更内容摘要
阅读官方网站、GitHub release note、changelog、migration guide，逐一确认变更前后之间所有版本的变更。从功能追加和 API 规格变更中，摘出可能与应用程序侧所用功能相关的内容。
代码与配置更新
区分两个观点进行确认：
- 因 API 或规格变更而需要的代码修正。若仅凭 release note 或 changelog 无法得知正确修改方法，需阅读 GitHub commit 差异和官方文档。
- 版本一致性。确认 pull request 中变更的版本号是否需要在仓库其他位置保持一致。
具体步骤：
- 从 diff 中确定变更前后的版本号。
- 判断更新对象类型，如 npm 包、运行时、Docker base image 等。
- 在仓库整体中寻找应同时更新的位置，确认“使用位置与版本指定位置”列表。例如 Node.js 运行时更新时，本地开发环境和 production 环境需保持一致版本，不仅要查 Dockerfile，还要确认
package.json和package-lock.json的 engines、packageManager、.nvmrc、CI 配置等。 - 将仍残留旧版本的位置写入报告。
不要仅凭版本字符串完全匹配搜索就判定无问题，因为可能存在范围指定或别名管理。Node.js 对应 npm 之类相关版本对应关系，不要推测，应以官方文档或实际发布物为依据。因外部访问限制无法确认时，写明未确认。
值得关注的更新
若存在可能应用于应用程序的新功能实现或概念发明、利用编程语言或运行时新功能的实现、开发体制变化等，需摘出。
过去的失败
以更新对象名称搜索该仓库的 pull request 和 issue，调查是否曾发生与更新对象相关的问题。例如未 merge 而关闭、merge 后出现故障又 revert 等案例。若发现，确认是否已解决。
含修正 commit 的 pull request 再审查
当指挥角色提供修正 commit 的 SHA 和列出需保持一致位置的文档位置时，除上述调查外，还需确认该 commit 的差异仅局限于该文档所列位置。若未限定，则不得将结论定为“无需修正即可 merge”。
最终确认
横跨报告整体，确认各节之间无矛盾或遗漏，发现则修正相应章节：
- 其他章节读到的文件是否包含在“使用位置与版本指定位置”列表中
- 列表中的引用位置是否在版本一致性确认中全部验证
- “依赖关系”信息与“变更内容摘要”是否矛盾
- “变更范围”中列出的包中，是否有“变更内容摘要”未说明依据或意图的。未说明的变更需作为注意点写入。
报告输出
读取 TEMPLATE.md，按该结构生成报告，并作为 pull request 评论发布。Reviewer 处填写自己的 Agent 名和 model 名。GitHub 上文章的写法遵循 kuden:github skill。其他仓库的 issue 和 pull request 需写完整 URL 而非编号，因为仅编号会链接到审查目标仓库的同编号。
当指挥角色提供标签名称时，发布后添加审查请求标签；判定为安全更新的报告也添加安全更新标签。结论为“暂缓判断”时，不添加审查请求标签。
向指挥角色汇报
简短书写。详细内容在报告中，不重复。
- 已发布评论的 URL 和结论
- 添加的标签（仅在添加时）
- “值得关注的更新”章节是否有内容
- 未能确认的事项及因无手段而无法完成的事项
- 步骤中模糊的点