该技能用于对开放中的 PR 做单轮处理：把评审意见、失败检查和基线冲突逐项分诊，修复、拒绝、延后或提请决策，并在每轮结束后复核 PR 是否偏离原本目的。使用者是“编排者”，负责分诊、把关、复核与报告；实际写代码由子代理完成。
核心概念
- 锚点（Anchor）：PR 的目的，写成可编号引用的行。来源依次为 PR 关闭的工单及其父规格、PR 正文、开发者口述。
- 漂移（Drift）：PR diff 中既无锚点行、也无已批准修复支撑的改动。
- 判定（Verdict）：Fix（意见成立且锚点需要）、Decline（意见错误或锚点不需要，如顺手改名改样式）、Defer（成立但超出锚点，转为后续工单）、Ask（需开发者做产品或设计决策）。
- 漏检（Miss）：本应更早发现该有效意见的阶段，包括 spec、implementation、tests、review。
前置条件 所有 PR 操作遵循消费仓库的 docs/agents/pull-requests.md（查找 PR、读评论、回复、解析线程、检查、重新自动评审、检出）；工单遵循 docs/agents/issue-tracker.md。若 pull-requests.md 缺失，应停止并用 PULL-REQUESTS-DOC.md 与开发者共同撰写，写好后再继续。
七个步骤
- 锁定锚点：从用户引用或当前分支找到 PR，按上述顺序取锚点，产出可被后续判定逐条引用的编号列表。
- 收集本轮：抓取所有行内评论、评审正文、会话评论与检查，并确认分支是否与基线冲突；完整阅读评审正文（自动评审摘要可能列出无行内评论的问题）。已往轮次的回复即记录，每条回复以判定开头；只有线程最后一条是自己的判定回复才算已结，他人后续回复会重新打开。对没有线程的条目，以链接来源的判定评论作为记录。失败检查需按 PR 文档重跑，区分偶发与真实失败。
- 分诊：建表，每行含序号、条目（链接、作者、主张）、判定、锚点（或 none）、漏检（Fix/Defer 需给出阶段与证据）、预防（能更早发现的一处改动及落点）。须对照代码自行验证主张，而非听信评论者。基线冲突单列一行，判定 Fix，无漏检与预防。展示表格后结束回合，等待开发者批准或修改判定。
- 修复：每项获批 Fix 用 FIX-BRIEF.md 交给子代理；改同一代码的合并为一个子代理；在 PR 检出中逐个运行，先处理基线冲突。每个子代理完成后亲自读其提交，核对是否只解决该项、测试是否运行，必要时退回返工。
- 复核：对整份 PR diff 逐块检查每个 hunk 是否可追溯到锚点行或获批 Fix，列出所有不追溯的 hunk；用仓库自身命令做类型检查并运行覆盖改动文件的测试；本轮提交超过约 200 行时另跑 code-review 技能。本轮修复引入的漂移或失败退回该子代理；其它发现（如往轮漂移）作为新行加入分诊表，待批准后再动。
- 发布：推送后逐项回复，以判定开头（Fixed in <sha>…、Declined:…、Deferred to <工单链接>:…），Ask 项暂不回复；无线程条目以链接来源的 PR 评论回复；自动评审线程在其修复落地后解析，人类线程留给人处理；按需请求新的自动评审，然后再次抓取 PR（自动评审有时会追加评论）。
- 报告：按四节汇报——本轮（各判定计数、推送提交、Ask 项及问题）、复核（漂移结果与各检查结果）、改进（按落点分组的预防条目，含改动、可捕获的条目、可直接粘贴的提示词；不自行应用）、就绪检查（每项有判定且已执行并回复、检查全绿、最新自动评审无新问题或仓库无自动评审、无基线冲突）。全部满足即提示可交由人工批准合并；若仍有新条目或评审待出，提示其落地后再运行本技能。