review-loop

Review Loop

有界的审查-修复-再审查循环。你是路由器——解析意图、选择审查者、运行循环。

1. 解析意图

根据 /review-loop 后的自然语言确定：

• 目标：计划还是工作？检查对话上下文、近期活动和用户的措辞。
• 审查者：由用户指定，或由你判断。可用项：code-reviewer、architect-reviewer、security-auditor、technical-editor、accessibility-tester、design-reviewer、codex-specialist。根据产物类型匹配。
• 轮数上限：默认为 3。用户可以说“彻底”（5）或“快速”（1）。
• 严重程度门槛：默认为 P2（修复 P0-P2，记录 P3 及以上）。用户可以说“严格”（P1）或“宽松”（P3）。

如果有歧义，询问：“要审查计划还是工作？”

2. 分派

• 计划：通过 Skill 工具调用 /plan-review。传入轮数上限。其内部 P0 循环计为 R1。
• 工作：通过 Agent 工具分派审查者。要求提供带严重程度标签的发现（P0-P3）。

未标记的发现：按 P1 处理。

3. 循环：修复、记录、再审查

对于每一轮（R1..R{cap}）：

a. 分类：根据严重程度门槛处理发现（P0 严重程度最高，P3 最低）：

• 修复（严重程度高于门槛——P 编号更低，即 P0 到 P{gate}）：立即修复。提交：fix: address R{N} review findings，并按照 AGENTS.md 添加 Co-Authored-By 页脚。
• 记录（严重程度低于门槛——P 编号更高，即 P{gate+1}+）：记录，不修复。

b. 记录低于门槛的发现：

• 计划：在计划文件中追加 ### Deferred Findings (R{N}) 部分。
• 工作：执行 gh issue create --label review-finding --title "R{N}: <summary>"。每轮最多 10 个，所有轮次累计最多 20 个。如果 gh 不可用，则追加到 .branch-context.md。

c. 保留审查者——绝不信任修复结果。审查者会一直留在审查组，直到其单独确认没有高于门槛的发现。只有这样才算完成。

• R1：完整审查组
• R2+：仅由上一轮中有高于门槛发现的审查者再次审查
• 没有高于门槛发现的审查者已完成——他们已默认批准

**d. 以下情况退出：**所有审查者均已单独确认无问题（达成一致），或达到上限，或给出 DROP 判定。

**e. 反复出现的发现：**如果同一发现出现在 2 轮或更多轮中，将其严重程度提升 1 级。如果升级后的发现达到 P0 且在达到轮数上限时仍未修复，则停止并移交人工处理。

4. 总结

Review Loop Summary
───────────────────────────────────────
Target:    <plan name or file description>
Rounds:    <N of cap>
Gate:      P<N>

│ Round │ P0 │ P1 │ P2 │ P3+ │ Fixed │ Recorded │
│───────│────│────│────│─────│───────│──────────│

Verdict: APPROVE | ESCALATE

APPROVE = 所有高于门槛的发现均已解决。ESCALATE = 仍有未解决的高于门槛的发现——移交人工处理。

防护措施

• 切勿修改受保护文件（参见 AGENTS.md）。
• 硬性上限：最多 5 轮，即使用户要求更多也不例外。注意：“彻底”（5）已经是上限。
• 不要自动合并或自动批准。循环只生成判定，不执行操作。
• 仅输出纯文本——确保跨界面安全。

失败情形

• /plan-review 不可用 → 直接分派 technical-editor + architect-reviewer。
• gh 未通过身份验证 → 改用 .branch-context.md 或打印列表。
• 审查者返回 DROP → 立即退出并打印总结。
• 没有可用的审查者 → 至少使用 code-reviewer 组成审查组。