debate-review

debate-review

两个模型会在发布任何内容前展开辩论。主审查者找出问题，辩论审查者则尝试推翻这些判断，也可能提出自己的问题。随后，主审查者作出最终决定，并将一条带有行内评论的审查发布到 PR 或 MR。它会以用户自己的 gh、glab 或 az 账户发布非批准审查或评论。它绝不会批准，也绝不会请求更改。

你是协调者。你只需运行一条命令并转达结果。你不亲自审查差异，也不操作 PR。

运行

node "<skill-dir>/scripts/review-pr.mjs" --local [--base <ref>]
node "<skill-dir>/scripts/review-pr.mjs" <pr-url | number> [--dry-run]

• 如果用户想要审查，但没有 PR/MR URL，请在仓库中运行 --local（或使用 --repo-dir）。不要编造 URL。转达 stdout。--local 不会与代码托管平台通信，并且会拒绝非 UTF-8 的 Git 路径，而不是有损解码。
• <pr-url> 可以是 GitHub /pull/N、GitLab /-/merge_requests/N 或 Azure DevOps /_git/<repo>/pullrequest/N URL（dev.azure.com 或旧版 *.visualstudio.com）。裸数字会根据当前工作目录的 origin 解析，包括 Azure DevOps https 和 ssh.dev.azure.com:v3/ 远程地址。
• --dry-run 会打印实时 PR 审查，而不是发布审查。它不能与 --local 同时使用。
• Azure DevOps 需要登录 az（az login），并拥有项目访问权限。无需扩展；脚本会通过 az rest 调用 REST API。在 Azure DevOps 中，审查由 N 个行内评论线程和一个已关闭的摘要线程组成，因为 Azure DevOps 没有单一的审查对象；提醒引用块会以普通引用形式呈现，但仍然清晰可读。
• 审查者是两个 delegate-skills 通道：review-main 和 review-debate。如果缺少任一通道，脚本会提示。使用 delegate-setup 添加它们。选择两个不同的实现者，因为只有当第二个模型没有第一个模型的盲点时，辩论才有价值（主审查者使用 claude 或 grok，辩论审查者使用高强度的 codex，是一个不错的组合）。如需临时指定，请传入 --main <implementer> 或 --debate <implementer>。只接受其 relay 支持 --read-only 的实现者。这两个通道归审查者专用。不要将它们指向你用于其他工作的通道，例如 plan-debate 通道。
• --check 会让每位审查者开始执行一条只读简报，并按角色打印 ok 或带原因的 FAIL，任何一项失败时退出码为 1。设置好通道后，请在每台机器上运行一次；它能在 PR 等待审查前发现审查者未安装、未登录、超出配额或被沙箱拒绝等问题。
• 退出码 3 表示当前 head sha 已有一条 debate-review。使用 --force 重新发布。
• 一次运行需要几分钟，因为会依次进行两到三次实现者会话。请在后台运行，并在完成后报告打印出的 URL。不要频繁轮询。

所有标志：--help。契约：references/schema.md。发布内容：references/comment-format.md。审查者简报位于 assets/prompts/，由脚本填充；你无需阅读。

发布之后

每条已发布的评论都带有 `` 标记。babysit-pr 可处理 GitHub 和 GitLab 的后续轮次（验证、修复阻塞问题、回复、解决）。它目前无法收集 Azure DevOps 的结果，因此请直接将 Azure 发现转达给用户。除非用户提出要求，否则不要自行处理这些发现。

产物

~/.cache/debate-review/<owner>__<repo>/<N>/<head>/ 中包含 run.json（全部三份文档、耗时和已发布内容），以及 main/、debate/ 和 final/，每个目录中都有发送的简报和 relay 的 result.json。 --local 会改为写入 ~/.cache/debate-review/local/<repo>/<branch>/<head>/。