用途：review-loop 用于对代码或计划进行迭代式审查。它借助一个全新的子代理审查者，找出问题、呈现发现、应用修复，并循环执行直到用户批准。适用时机包括：实现非平凡改动之后、执行前验证计划、审计代码的正确性/风格/安全问题，以及任何需要独立第二意见的场景。
主要能力与严重级别：发现的问题标注四级严重度——critical（正确性缺陷、安全漏洞或数据丢失风险，必须修复）、high（可能的缺陷、竞态条件或重大设计缺陷，应当修复）、medium（代码异味、逻辑不清、缺少边界情况或可维护性问题，建议修复）、low（风格细节、命名建议、小幅改进，酌情修复）。
使用方式：先确定审查目标（按路径的源文件、会话或对话中的计划、diff 或改动集、特定函数/类/模块），收集完整内容。若指定了特定视角（如 correctness-lens、security-lens、adversarial-lens 等），使用对应命名视角代理以审查模式运行，否则使用通用审查者。启动子代理时给出提示结构，要求从正确性、安全、性能、可读性和项目约定遵循度审查，并按 [SEVERITY] 标题、Location、Problem、Suggestion 的格式报告，按严重度排序，不得编造问题，无问题需明确说明；代码只读审查用 Explore 子代理，若需运行测试或执行代码验证，则标记为未验证发现，交由主代理处理。审查者返回后，按严重度分组列出全部发现及建议修复，若无问题则明确报告，并询问用户处理哪些发现（可全部批准、选择特定项、驳回或请求澄清）。对每个获批发现实施修复并简要确认；若修复非平凡或有歧义，应向用户寻求指引而非猜测。修复后询问是否再跑一轮，用户需要则带着更新后的目标回到第 2 步，满意则退出循环。
限制与准则：每轮使用全新上下文，审查子代理不带先前轮次记忆，避免锚定偏差；未经批准不得自动修复，必须等待用户决定；对 critical 或 high 级发现应先尝试验证（如运行测试或追踪代码），未验证的需标注；循环应有界，若连续两轮仅返回 low 级发现，建议退出循环。