fusion-dependency-review

依赖项审查

用于依赖项更新 PR 的结构化审查工作流。生成一致的研究记录，纳入现有 PR 讨论、多视角分析，以及可执行的结论，并在执行任何合并操作前明确征得维护者确认。

适用场景

当需要审查依赖项 PR，并希望采用一致且可审计的决策流程时使用。

典型触发条件：

• “审查这个依赖项 PR”
• “我们应该合并这个依赖项更新吗？”
• “检查这个 Renovate/Dependabot PR”
• “审查一个待处理的依赖项 PR”
• “这个库版本升级有哪些变化？”
• “这个依赖项更新可以安全合并吗？”
• PR 标题包含依赖项更新模式（例如 chore(deps):、fix(deps):、bump、update）
• 用户分享了依赖项更新 PR 的 URL

不适用场景

• 功能 PR 或应用代码审查（使用标准代码审查工作流）
• 依赖项自动化或机器人配置
• 未经用户明确确认就批准或合并
• 制定组织的依赖项策略

必需输入

开始前收集：

• 仓库所有者和名称
• PR 编号或 URL，或包含软件包名称、版本变更、已更改文件和 CI 状态的 PR 摘要副本
• 可选：具体的审查关注点或重点领域

如果缺少必需信息，请根据 references/questions.md 提出简洁的澄清问题。

如果 PR 目标缺失或不明确：

• 仅提出识别目标 PR 所需的最少后续问题。
• 已知仓库上下文时，使用 GitHub MCP 列出可能的待处理依赖项 PR，让用户选择。
• 候选列表应简洁：在可用时包含 PR 编号、标题、依赖项/软件包提示、作者和 CI 状态。

有相关信息时，自动从 PR 中提取：

• 正在更新的软件包及版本范围（从 → 到）
• 更新日志/发行说明 URL
• CI 状态
• 已更改的文件和依赖项生态系统
• 现有的 PR 顶层评论、审查评论以及未解决的讨论串状态

说明

首选顾问编排方式

当运行时支持技能本地顾问时，优先采用以下执行方式，而不是单一的长线性流程：

1. 当 PR 目标缺失或不明确时，先运行 agents/target-pr-advisor.md，确保审查从一个明确的依赖项 PR 开始。
2. 运行 agents/research-advisor.md，规范化 PR 上下文、现有讨论、来源列表和研究记录。
3. 使用相同的规范化输入，并行分派各个视角的顾问：

• agents/security-advisor.md
• agents/code-quality-advisor.md
• agents/impact-advisor.md

4. 将整合后的研究结果和各视角输出传递给 agents/verdict-advisor.md，以生成建议、置信度、就绪状态、交接内容和确认措辞。
5. 仅当已接受的下一步需要修改 PR、变基、解决冲突或进行合并就绪工作时，才接着运行 agents/source-control-advisor.md。

各视角顾问应保持职责范围精简且相互独立。父技能负责统一审查，并应保留顾问之间的分歧，而不是过早地将其消解。

工作流摘要

1. 使用 agents/target-pr-advisor.md 和 references/questions.md 中的简洁提示来确定目标 PR。
2. 使用 agents/research-advisor.md、assets/review-tracker.md 和 assets/research-template.md 收集上下文并构建共享证据包。
3. 使用相同的规范化研究包，并行运行 agents/security-advisor.md、agents/code-quality-advisor.md 和 agents/impact-advisor.md。
4. 使用 agents/verdict-advisor.md 给出建议、置信度、就绪状态、后续跟进和明确的维护者确认提示。
5. 仅在结论获接受后，并且仅在需要分支操作时，才使用 agents/source-control-advisor.md。
6. 遵循 references/instructions.md 中关于实时 PR 约定的详细说明：目标选择、检查点评论、决策关卡和交接时机。

资源

• assets/research-template.md：用于变更摘要、破坏性变更、已知问题和来源的研究评论结构
• assets/verdict-template.md：用于各维度评估、建议、置信度、就绪状态和后续事项的结论结构
• assets/review-tracker.md：用于记录上下文、验证、各维度结论和交接决策的工作检查清单与跟踪表

参考资料

• references/instructions.md：有关目标选择、实时 PR 检查点和决策顺序的详细执行约定
• references/questions.md：用于选择目标依赖项 PR 和界定审查范围的简明后续问题

顾问

• agents/target-pr-advisor.md：确定要审查的确切依赖项 PR，或返回候选列表供用户选择
• agents/research-advisor.md：第一步；为所有后续顾问整理共享证据包
• agents/security-advisor.md：并行评估；检查安全态势和攻击面变更
• agents/code-quality-advisor.md：并行评估；检查上游稳定性、回归问题和 API 偏移
• agents/impact-advisor.md：并行评估；检查仓库影响范围、CI 和后续工作
• agents/verdict-advisor.md：链式综合评估；将研究和各维度的输出整合为一个决策
• agents/source-control-advisor.md：有条件的最终评估；在需要修改 PR 时处理变基、同步、重新运行验证和推送安全

如果无法使用辅助顾问，请遵循相同的编排顺序：先研究，再进行各维度评估，之后给出结论；仅在需要修改时，最后处理源代码管理。

预期输出

如果尚未确定 PR 目标，请返回：

• 在可以搜索实时 PR 时，提供简洁的候选依赖项 PR 列表
• 让用户选择正确 PR 所需的最少后续问题
• 明确状态：Awaiting user PR selection

如果已确定 PR 目标，请返回结构化审查，包含：

• 软件包名称、版本变更和更新类型
• 现有 PR 讨论摘要（顶层评论、审查线程主题、尚未解决的问题）
• 研究摘要（变更日志要点、破坏性变更、已知问题）
• 有证据支撑的安全评估
• 有证据支撑的代码质量评估
• 有证据支撑的影响评估
• 结论：建议、理由、置信度、就绪状态和后续事项
• 后续工作应转为跟踪议题时的交接建议
• 提示维护者采取行动

安全与约束

• 此技能具备修改能力。如仓库本地工作流说明与内联指导发生冲突，以仓库本地工作流说明为准。

绝不：

• 未经用户明确确认，不得合并或批准依赖项 PR
• 不得通过将基础分支合并到 Dependabot 或 Renovate PR 分支来创建合并提交
• 存在多个可能的依赖项 PR 时，不得猜测要审查哪个 PR
• 不得跳过在线 PR 上的研究检查点评论或最终结论评论
• 不得因为现有审阅者的疑虑不方便或内容重复，就置之不理
• 未核实实际状态，不得声称 CI 已通过或安全方面没有问题
• 不得在评论或日志中泄露密钥或令牌
• 不得为了方便而驳回安全疑虑
• 不得编造来源中没有的变更日志条目或版本详情

始终：

• 目标 PR 缺失或含糊不清时，提出尽可能少的后续问题
• 为每项评估提供证据（变更日志、CVE、CI 状态的链接）
• 分别评估技术建议、证据可信度和机械合并就绪情况
• 将待处理的检查或必需的批准视为就绪门槛，而非技术上的搁置理由
• 对重大更新要求提供明确的兼容性证据，但不要仅因 semver 类别就认为可信度低
• 存在仓库上下文但未指定目标 PR 时，列出候选依赖项 PR 供用户选择
• 在分析在线 PR 前，通过 GitHub MCP 获取现有 PR 评论和审查讨论串
• 在各顾问之间复用同一份共享研究资料，而不是在每轮分析中重复查找相同事实；资料包括 PR 元数据、变更文件、CI 状态和现有讨论
• 不要让各位顾问分别重新获取 PR 评论或审查讨论串；将研究顾问预先获取的数据传递给所有分析顾问
• 运行环境支持时，优先并行进行多角度分析；待所有分析结果就绪后，再串联进行综合
• 在线 PR 上进行任何分支修改前，先向 PR 发布研究检查点评论
• 在线 PR 上进行任何批准或合并前，先向 PR 发布最终结论评论
• 修改 PR 前，明确说明是否需要同步分支或变基
• 需要刷新时，将依赖项 PR 分支变基到最新基础分支；不要将基础分支合并到 PR 分支
• 明确说明后续工作，不要将其隐含在审查说明中
• 尊重维护者作为最终决策者的角色
• 以一致、可重复的结构组织审查结果