审查依赖更新 PR 时如何做结构化研究…

当需要审查依赖更新 PR（如 Renovate/Dependabot）并给出可审计的合并建议时使用。

适用场景

解决思路

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 打补丁、rebase、冲突解决或合并就绪工作时，才串联到 agents/source-control-advisor.md。
6. 保持各视角顾问范围狭窄且相互独立；父技能负责统一审查，并保留顾问间的分歧而非过早抹平。
7. 按工作流执行：1) 用 agents/target-pr-advisor.md 和 references/questions.md 中的简洁提问确定目标 PR；2) 用 agents/research-advisor.md、assets/review-tracker.md 和 assets/research-template.md 收集上下文并构建共享证据包；3) 用同一份规范化研究包并行运行安全、代码质量、影响三个顾问；4) 用 agents/verdict-advisor.md 产出建议、置信度、就绪度、后续事项和明确的维护者提示；5) 仅在结论被接受且需要分支操作时使用 agents/source-control-advisor.md；6) 遵循 references/instructions.md 中关于目标选择、检查点评论、决策门和交接时机的详细实时 PR 契约。
8. 若辅助顾问不可用，则按相同编排内联执行：先研究，再视角，然后结论，最后仅在需要变更时做源码控制。
9. 开始前收集必需输入：仓库 owner 和名称；PR 编号或 URL，或包含包名、版本变更、变更文件、CI 状态的 PR 摘要；可选的特定审查关注点。
10. 若缺少必需细节，从 references/questions.md 中提出简洁的澄清问题。
11. 若 PR 目标缺失或含糊：只问识别目标 PR 所需的最小后续问题；当已知仓库上下文时，用 GitHub MCP 列出可能的开放依赖 PR 让用户选择；候选列表保持简洁，包含 PR 编号、标题、依赖/包提示、作者和 CI 状态。
12. 从 PR 中自动提取：被更新的包及版本范围（from → to）、changelog/发布说明 URL、CI 状态、变更文件与依赖生态、已有顶层 PR 评论、审查评论和未解决线程状态。
13. 若 PR 目标未解决，返回：可用实时 PR 搜索时的候选依赖 PR 简洁列表、让用户选择正确 PR 所需的最小后续问题、明确状态 Awaiting user PR selection。
14. 若 PR 目标已解决，返回结构化审查，包含：包名、版本变更和更新类型；已有 PR 讨论摘要（顶层评论、审查线程主题、未解决关注点）；研究摘要（changelog 要点、破坏性变更、已知问题）；带证据的安全评估；带证据的代码质量评估；带证据的影响评估；结论：建议、理由、置信度、就绪度和后续事项；当后续工作应成为跟踪 issue 时的交接建议；给维护者的明确行动提示。
15. 始终：目标 PR 缺失或含糊时提出最小后续问题；为每项评估提供证据（链接到 changelog、CVE、CI 状态）；独立评估技术建议、证据置信度和机械合并就绪度；将待定检查或必需批准视为就绪门，而非技术上的搁置理由；对主版本更新要求明确的兼容性证据，而不单凭 semver 类别就判定低置信度；当仓库上下文存在但 PR 目标不存在时，列出候选依赖 PR 供用户选择；在实时 PR 上分析前通过 GitHub MCP 获取已有 PR 评论和审查线程；在所有顾问间复用同一份共享研究包，而不是每轮重新发现相同事实——包括 PR 元数据、变更文件、CI 状态和已有讨论；不要在每个顾问中独立重新获取 PR 评论或审查线程，而应将研究顾问预取的数据传给所有视角顾问；运行时支持时优先并行视角分析，然后在所有视角输出就绪后串联综合；在实时 PR 上做任何分支变更前，先将研究检查点评论发布到 PR；在实时 PR 上做任何批准或合并前，先将最终结论评论发布到 PR；在给 PR 打补丁前明确分支同步或 rebase 需求；需要刷新时，将依赖 PR 分支 rebase 到最新基分支，不要将基分支合并进 PR 分支；将后续工作显式化，而不是埋在审查笔记中；尊重维护者为最终决策者；保持审查输出结构一致、可复现。
16. 绝不：未经用户明确确认就合并或批准依赖 PR；通过将基分支合并进 Dependabot 或 Renovate PR 分支来创建合并提交；存在多个可能依赖 PR 时猜测要审查哪个；在实时 PR 上跳过研究检查点评论或最终结论评论；因为已有审查者关注点不便或重复就忽略它们；未检查实际状态就声称 CI 通过或安全无虞；在评论或日志中暴露密钥或令牌；为方便而忽视安全问题；编造来源中不存在的 changelog 条目或版本细节。
17. 使用资产：assets/research-template.md 用于变更摘要、破坏性变更、已知问题和来源的研究评论结构；assets/verdict-template.md 用于视角评估、建议、置信度、就绪度和后续事项的结论结构；assets/review-tracker.md 用于上下文、验证、视角结果和交接决策的工作清单与跟踪器。
18. 参考 references/instructions.md 获取目标选择、实时 PR 检查点和决策顺序的详细执行契约；参考 references/questions.md 获取选择目标依赖 PR 和界定审查范围的简洁后续问题。

适用边界 · 注意事项

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