codex-review-loop

Codex 评审循环

通过循环让 PR 符合 ChatGPT Codex 的在线 GitHub PR 评审要求，然后合并。 这里没有隐藏的基础设施——只有 gh、随附的轮询脚本，以及下面的纪律要求。

机械部分（触发 + 双信号轮询 + 提取发现项）位于 codex-review-loop.sh。判断部分（修复发现项、验证、决定是否合并）由你负责。

前置条件（先检查）

• 仓库必须已启用 ChatGPT Codex 的 GitHub PR 评审集成（组织/仓库设置）。 评审会在 PR 打开、从草稿转为就绪，或有人评论 @codex review 时触发。机器人账号： chatgpt-codex-connector[bot]。如果仓库未连接，此循环就无法运行——请明确说明。
• 已通过 gh 完成身份验证（gh auth status），并已安装 jq。请在仓库内运行脚本 （脚本会通过 gh repo view 自动检测 owner/name）。

循环

在后台运行脚本（轮询间会休眠），以便任务完成时重新调用；不要在前台休眠。

1. 触发并轮询一轮。 bash <skill>/codex-review-loop.sh run <PR> 会发布 @codex review （先记录 UTC 基准时间）并等待。脚本只会打印一行判定结果：
   • RESULT=FORMAL_REVIEW id=<rid> ... inline_comments=<n> → Codex 发现了问题；脚本还会 打印行内发现项（FILE: path:line + 正文）。
   • RESULT=CLEAN ... / RESULT=CLEAN_REVIEW ... → 本轮没有重大问题。
   • RESULT=TIMEOUT → 重新运行，或手动检查 PR。
2. **如果发现问题：**逐一处理。修复前，先根据实际情况核实 Codex 的说法—— 它可能判断有误（例如，它可能声称代码中不存在的 API 结构；请检查源码）。修复 实际问题（并优先修复整类问题，而不只是单个实例）。然后在本地验证（编译 / 单元测试 / lint / API 门禁——以仓库实际使用的为准），再推送。提交、推送，然后返回第 1 步。 推送 = 新提交 = 清洁计数器重置。
3. 如果结果干净：这是第 1 次干净。在同一提交上再触发一次（再次运行 run <PR>，不创建新提交）。Codex 的结果具有非确定性——对同一提交重新评审 可能会发现新问题（实践中观察到过）。只有连续两轮干净后，才能继续合并。
4. 合并（仅在获得用户对该仓库合并策略的授权后）： gh pr merge <PR> --merge --delete-branch。然后同步本地 main。

脚本为何轮询两种信号

Codex 通过两种不同方式报告结果，因此只轮询一种会漏掉一半的判定：

• 发现问题 → 正式的评审（/pulls/<PR>/reviews，state=COMMENTED）以及行内 评论，行内评论通过 pull_request_review_id 与对应评审关联。
• 结果干净 → 议题评论（/issues/<PR>/comments），正文为 "Didn't find any major issues"。

两种信号都会按机器人登录名以及晚于触发时记录的基准时间进行筛选，因此不会把之前过时的评审误认为新结果。机器人发出的 "Codex is reviewing…" 确认消息会被忽略， 因为它不符合干净结果的措辞。

重要纪律（都是经验教训）

• **合并前必须连续两轮干净。**单轮干净还不够；Codex 的结果具有非确定性。
• **修复前先核实。**把发现项当作待核实的说法，而不是事实。如果某项说法不适用于 当前代码库，不要盲目“修复”（否则可能让通过的门禁变成失败）。请提供证据进行回复/ 反驳，或通过改进稳健性来解决其背后的顾虑。
• **推送前先验证。**每项修复都应先通过仓库的本地门禁——不要把评审轮次浪费在编译错误上。
• **每轮只处理一个顾虑也可以。**后期轮次经常只发现一个 P2/P3 问题；逐步解决即可。
• **合并决定由用户作出。**先确认一次合并策略；未经授权，不要自动合并仓库。

适配其他仓库

• 通常无需更改——仓库会自动检测。如果机器人的登录名或 clean 短语有所不同，请编辑脚本顶部的 BOT / CLEAN_RE。
• 如果审核队列处理较慢，请调整 maxIters / interval（poll/run 的第 3 和第 4 个参数）。
• 合并策略：根据仓库的惯例，将 --merge 换成 --squash/--rebase。