Claudex 循环 是做什么的？
当前对话拥有需求、规划和协调的主权。另一个工具负责审查计划。任一工具均可构建；未参与构建的工具将在全新会话中检查最终代码。
一次性明确角色
根据运行时而非 PATH、已安装技能、模型名称猜测或仓库来识别实际宿主。两个 CLI 可能都已安装。在 Claude Code 中使用 host=claude，在 Codex 中使用 host=codex。如果运行时身份不可用，则询问用户正在使用哪个宿主（仅一次）。
| 宿主 | 需求与计划 | 计划审查者 | 默认构建者 | 最终检查者 |
|---|---|---|---|---|
| Claude Code | 当前 Claude 会话 | Codex | Claude | 全新 Codex 会话 |
| Codex | 当前 Codex 会话 | Claude | Codex | 全新 Claude 会话 |
遵循 builder=claude|codex。检查者始终是另一个工具。即使由另一个工具构建，宿主仍保持协调者角色。若要交换规划者，请在另一个宿主中开始对话；不要假称 CLI 审查者是用户的规划对话。
模型选择与工具角色无关。保留宿主的选定模型。审查/构建的 CLI 调用继承其自身配置，除非提供了 reviewer_model、builder_model 或 inspector_model；将这些映射到对应调用的 --model 参数。类似地应用显式的 *_effort。Fable 5.1 和 GPT-6 Astra 是合适的显式选择，而非强制固定。宿主界面中的模型并不能证明独立的 CLI 会使用哪个模型。分别报告请求和观察到的模型信息；诚实地报告未解决的 CLI 默认值。切勿在失败时默默地回退到其他模型/工具。
在启动 CLI 之前，阅读运行时参考。相对于此安装的 SKILL.md 来解析其运行器，永远不要相对于被审查的项目。启动时使用绝对路径。
如果用户提供了 codex_cli 或 claude_cli，则将所选工具的可执行文件路径映射到 --cli。宿主应用可能拥有比 PATH 上的 CLI 更新的工作二进制文件；验证路径和版本，不要静默更改全局安装或配置。
可调参数
| 参数 | 默认值 | 含义 |
|---|---|---|
PLAN_FILE / plan | PLAN.md | 全程使用的计划路径，包括构建交接 |
LOG_FILE / log | PLAN-REVIEW-LOG.md | 仅追加的日志记录 |
rounds / MAX_ROUNDS | 5 | 最大计划审查轮数 |
builder | host | 实现计划的工具 |
research | 与任务成比例 | none、web 或显式选择加入的 deep |
mode | full | full 包括侦查/访谈；review 从现有计划开始 |
inspect | on | 仅当用户显式选择退出时为 off；记录该决定 |
MAX_FIX_ROUNDS | 2 | 在报告或接管之前的有界构建修复尝试次数 |
MAX_INSPECTION_ROUNDS | 2 | 初始检查加修复后的一次 |
在开始前回显角色、路径、轮数限制、请求的模型和检查退出选择。保留现有授权：请求规划不授权构建；请求规划并实施则授权。在寻求任何剩余的批准之前，执行已授权的准备工作。
阶段 0 — 侦查
对于现有项目，检查相关代码、依赖项、共享状态的调用者和写入者。阅读现有的 CONTEXT.md / CONTEXT-MAP.md 以及相关的 ADR。对于全新项目，在有用时研究先前技术、合理的栈和具体的失败模式。尊重显式的研究深度。深度多代理研究需要显式选择加入和可用工具；否则，使用支持的针对性研究并报告限制。不要要求专有的 Workflow 工具或硬编码研究代理模型。
通过宿主的可用目录和另一个工具记录的技能位置（当可访问时）发现相关技能。仅记录相关的提议依赖项。不要假设宿主 MCP、浏览器、凭据或技能会转移到另一个 CLI。在依赖构建能力之前验证它们。
提供一份包含源路径或研究链接的假设清单。一次性提问以纠正重大不确定性。在用户已授权工作时，自行处理常规的可逆选择；沉默不等同于批准需要批准的行动。
阶段 1 — 确定需求
维护一个简短可见的决策图。仅提问那些未解决且会改变结果的决定。对于每个重要的提问，给出推荐理由、其重要性以及猜错的代价。批量提出独立问题；按顺序提出依赖性问题。如果代码可以回答，则检查代码。当长长的决策列表会拖慢用户时，提供“接受所有剩余建议”选项。
尊重现有的术语表定义；解决有歧义的领域语言。使用 CONTEXT-FORMAT.md 懒惰地维护仅术语表上下文。仅对难以逆转、非显而易见的权衡使用 ADR-FORMAT.md 记录 ADR。
编写已解决的 PLAN_FILE，包含：
- 目标和可观察的验收标准。
- 具体方法、关键决策、权衡和非目标。
- 经确认的假设及其来源和剩余风险。
- 每个工具的相关工具链要求（如有）。
- 验证：确切的证明命令、预期结果以及需要的手动/视觉检查。
尽可能从仓库推导证明命令。仅当成功标准不清楚时才提问。使用角色、模型请求、范围、授权和轮数限制初始化仅追加的 LOG_FILE。将运行时诊断信息保留在检出目录之外。
使用 mode=review，加载提供的计划，仅在需要时与用户一起填补实质性空白，然后直接进入审查；不要重新开始需求访谈。
阶段 2 — 独立计划审查
使用共享运行器的 review 模式，带有实际的 --host、已解析的 --plan 和可选的模型/effort。第一轮创建会话。后续轮次使用 --resume <previous-successful-result.json> 以及相同的工具/模型/effort 和宿主编写的包含处理意见的 --feedback 文件。切勿使用猜测的会话 ID、--last 或将构建会话用作审查者。
每个成功响应包含裁决、有证据支持的发现、实际覆盖范围和限制。将整个响应和运行器结果路径保留在 LOG_FILE 中。
- 批准： 没有未解决的重大缺陷。批准绑定到确切的计划路径和 SHA256。呈现剩余的低优先级建议和限制；零发现是有效的，并不证明是彻底的正确性。
- 修订： 宿主对每个发现进行仲裁。实施有理由的计划更改；拒绝无支持的建议并提供理由。记录处理意见并将修订后的计划发送给同一审查者。避免在没有新证据的情况下重新讨论已解决的点。
- 阻止 / 过程失败 / 结果格式错误： 切勿将其计为批准。解释实际缺失的证据或操作失败。不要在盲目的重试上浪费剩余轮数，也不要默默地切换工具。
在 MAX_ROUNDS 时停止。呈现未解决的发现和宿主的立场，而不是人为制造趋同。更改后的计划需要再次审查。在构建之前，对最终计划运行批准检查。如果用户明确选择在未独立批准的情况下继续，则记录该覆盖并使用独立的未审查规范路径；切勿将其标记为已批准。
阶段 3 — 构建与检查
呈现已审查的计划、改进和剩余限制。如果实施尚未授权，则请求最终决定。使用选定的构建者，默认为宿主。阅读构建参考。
宿主可以使用其常规工具直接实施。对于不同的构建者，使用共享运行器的 build 模式。任一路径都必须捕获构建前的提交、保留不相关的用户工作，并携带相同的已解决计划和验证合约。
运行商定的证明检查，检查所有更改的文件，并通过另一个工具在全新的 inspect 会话中审查结果。提供构建前的提交和构建者身份。接受修复后的重新检查也使用全新会话。记录发现和处理意见；在修复后重新运行受影响的证明检查。
如果协调者接手编码，则其已成为构建者。要求另一个工具对其更改进行全新检查；切勿将早前的检查描述为涵盖了后续编辑。如果两个工具都贡献了代码，则记录作者身份，并让每个工具检查另一个工具的更改；不要声称任何模型独立审查了其自己编写的代码。如果检查预算已用完，则明确报告剩余发现和未审查的编辑，供用户决定。
呈现最终差异、证明结果、检查覆盖范围、未解决的发现、偏差和使用过的轮数。尊重现有的提交/推送授权；否则将具体差异准备好以待批准。仅运行循环并不意味着外部发布。