dependency-update

用途

本技能是针对依赖更新拉取请求（PR）定期处理流程的“指挥部”技能。它面向由 Dependabot 或 Renovate 创建的依赖更新 PR，按仓库预先设定的自动化阶段，依次推进审查、修复、合并。这里的“依赖”不仅指库，还包括 Docker 镜像、GitHub Actions 和运行时。

主要能力

作为指挥部运行，按 kuden:orchestrator 技能的标准行事；指挥部本身不阅读 PR 差异，也不阅读仓库代码。
将单个 PR 的审查与修复分配给每件 PR 单独启动的 subagent，要求使用 Opus 及以上层级的模型。
依据审查评论与修复 subagent 的评论判断 PR 进展，不使用标签判定；标签仅用于向人展示状态，且只在启动提示中指定名称时才添加。
合并只能由指挥部执行，subagent 不得合并。
将本次运行的发布内容汇总到通知目的地的一个 thread 中：先发一条作为父帖，后续以回复形式发布。

使用方式

启动提示由 dependency-update-setup-routine 技能生成，从中接收三类值：

目标仓库列表及各仓库的自动化阶段（“审查为止”“修复为止”“合并为止”之一）。列表之外的仓库 PR 不审查、不重跑 CI、不请求 rebase。
可选的标签名称，涵盖审查请求、合并批准、安全更新三类；按仓库不同时写在对应仓库行。
通知目的地（如 Slack 频道），需能把回复归入同一 thread。

必填值缺失时：可交互环境询问补全；无人值守时报告缺失项并结束。

运行前环境检查（不满足则不执行任何操作，报告后结束）：自身模型为 Opus 及以上层级（Opus、Fable、Mythos 等；Sonnet、Haiku 等低层级即使代际更新也不满足）；能启动 Opus 及以上层级的 subagent；具备读取 GitHub PR 与发表评论的手段（需自行发现本会话可用的集成方式）。修复需要向分支 push 的手段，合并需要合并手段与向通知目的地发布的手段；缺少某手段的工序不执行，并写入完成报告。

合并所必需的 CI

以 PR 基础分支的保护规则中指定为合并必需的 check 作为“合并必需的 CI”，branch protection 与 ruleset 两种指定方式同等对待。必需 check 列表即使没有读取保护规则设置的权限，也可从基础分支信息读取。非必需 check 即使失败也不阻止合并，也不重跑。未指定必需 check 的仓库，以及无法读取指定时，将所有 CI 视为必需；无法读取时在完成报告中说明理由。

处理流程

1. 审查

对象为列表内仓库中 Dependabot 或 Renovate 创建的 open PR，且满足以下任一：无审查评论；最新审查评论结论为“判断保留”；更新依赖与版本与最新审查评论记载不同（bot 更新到新版本时，bot 的 rebase 不改变版本，故不重新审查）；修复 subagent 最新评论中的 commit 包含在 PR 中且该评论晚于最新审查评论（修复后未等到 CI 而遗留的情况，按与修复后相同的 CI 等待方式重新审查）；最新审查评论以修复 commit 为前提但该 commit 不在 PR 中（bot 重建时，按普通审查重新审查）。对象为 0 件则进入第 2 步。

每件 PR 启动新 subagent 运行 dependency-update-report；同仓库多个 PR 并行时，各 subagent 使用独立工作目录。指示需包含 PR 位置（仓库名与编号）、标签名（仅启动提示中有则传）、代码阅读位置与工作目录、报告语言（启动提示有指定则用，否则用启动提示语言）；对于含修复 commit 的 PR 重新审查，还需传修复 commit 的 SHA 与对齐位置文档的地址（均在修复 subagent 的评论中）。

需确认报告已作为评论发布到 PR；有标签名时，除结论为“判断保留”者外，还需确认已加标签。

2. 修复

仅修复自动化阶段为“修复为止”或“合并为止”的仓库 PR，且在第 1 步审查结束后开始。若有审查 subagent 未完成，该 PR 留待下次运行，继续修复其他 PR。

修复对象需同时满足：由 Dependabot 创建；最新审查评论结论为“修正需要”；更新依赖与版本与最新审查评论一致；所有 commit 均为 bot 的；最新审查评论之后没有 dependency-update-fix 标记为“对象外”的评论；没有人未撤回的 changes requested、合并反对或保留要求。需读仓库文档才能判断的条件，由 dependency-update-fix 在着手前确认；不满足的 PR，subagent 不做改动，在 PR 评论报告对象外及理由，下次运行起在重新审查前不作为修复对象。

每件 PR 启动新 subagent 运行 dependency-update-fix，指示包含 PR 位置、标签名（仅启动提示有则传）、clone 位置与工作目录。

修复之后

对 subagent push 的 commit 的 CI 结束后，按第 1 步相同方式重新审查。合并必需的 CI 失败时，在重新审查前将该 job 重跑一次。等待 10 分钟仍未结束时，留待下次运行重新审查。

3. 合并

仅合并自动化阶段为“合并为止”的仓库 PR。所有 subagent 的审查与修复结束后，读取 merge.md 并按其规定由指挥部执行合并。有未完成的 subagent 时，该 PR 留待下次运行，继续其他合并。

通知

本次运行的发布汇总到通知目的地的一个 thread：首次发布为父帖，后续作为其回复。合并的计划与结果发布由 merge.md 规定。

全部合并结束后，将本次第 1 步审查的 PR 中报告“感兴趣的更新”一节有内容者汇总为一条发布（含修复 commit 的 PR 重新审查、结论为“判断保留”者除外），每件 PR 写仓库名、更新对象名与更新前后版本、感兴趣的更新要点 2～3 行、报告评论的 URL；自动化阶段为“审查为止”的仓库 PR 也发布。

随后，将本次运行中判断需要人决策的 PR 汇总为一条发布，包括：本次审查结论为“修正需要”但第 2 步未修复者（自动化阶段为“审查为止”的仓库 PR，及不满足第 2 步对象条件者）；本次由 dependency-update-fix 报告为对象外者；本次第 2 步修复后重新审查结论仍为“修正需要”者（不再叠加修复 commit）；本次审查结论为“不可合并”者。每件 PR 写仓库名、更新对象名与更新前后版本、报告要求事项的要点、未自动推进的理由、报告评论的 URL。

若合并对象、merge.md 规定搁置的 PR、感兴趣的更新、需人决策的 PR 均无，则不发布。

需遵守事项

对 Dependabot 与 Renovate 的 PR 分支，除第 2 步修复 subagent 叠加一个修复 commit 并 push 外，不提交、不 push 任何 commit。
各 PR 独立处理，一件失败不影响其他。
GitHub 上发布的评论需写明撰写 Agent 的名称与模型名，subagent 同样如此。

完成报告

简报已发布审查评论的 PR、已修复的 PR、因已审查而跳过的对象、已合并者、合并候选但未合并者及理由。如因无法访问 GitHub 或通知目的地等未能执行，需写明原因。

限制

仅适用于 Dependabot 与 Renovate 创建的依赖更新 PR。
要求自身及 subagent 模型为 Opus 及以上层级。
需具备 GitHub PR 读写、分支 push、合并与通知发布等相应手段，缺少某手段的工序不执行。
工具的具体收费、价格、平台支持与效果等资料暂未提供。

技能介绍

用途