用途
Iterate 是一个“构建者/评审者”迭代改进循环，采用评估器-优化器（evaluator-optimizer）模式，适用于任何可评审的交付物——代码、文档、设计、研究等。
它适合在“初稿质量不足、且目标可被客观检验”的场景下使用。如果任务过于琐碎，或评判标准纯粹是个人品味，协议要求直接说明并改为直接完成。
主要能力
- 适配性检查：先判断迭代循环是否值得使用。
- 目标与范围定义：把目标重述为精确、可检验的一段话，并给出明确成功标准；若未提供则询问。
- 范围（Scope）：列出构成工作的文件/目录。工作不一定是代码，但每个交付物都必须以范围内的文件形式落地，因为评审者只能审查文件。
- 验证策略（Verification policy）：规定在该媒介中如何检验主张。代码：要运行的命令/测试；文档/研究：引用可解析、数字可重算、内部一致、覆盖必需要点；设计/计划：每个元素可追溯到需求。每种媒介都要有具体检查，“读起来通顺”不算策略。
- 运行目录：在 git 仓库中通过
git rev-parse --show-toplevel确定项目根（若 .gitignore 中缺少 .iterate/ 则添加），否则使用当前工作目录。以原子方式创建运行目录.iterate/<YYYYMMDD>-<short-slug>/——使用不带 -p 的 mkdir，遇到已存在失败则重试 -2、-3……，确保并发运行不会共享目录。将目标、范围、验证策略写入<run>/GOAL.md，后续所有轮次文件都放在<run>/下。 - 选项解析：
max-rounds=N（默认 5）与lenses=a,b,...——可选的命名评审视角（如 security、prose-clarity、api-design）。若没有列出的视角覆盖目标一致性，则追加一个通用视角，否则没有任何视角检查工作是否满足目标。省略时，每轮一个通用评审者，即经典行为。
使用方式
每轮（n = 1, 2, ...）
- 构建（Build）：第 1 轮实现目标；第 2 轮及以后应用上一轮裁决中的所有 BLOCKER/MAJOR 发现。然后按验证策略重新验证整个工作，而不只是改动部分——修复发现的同时悄悄破坏原本正常的行为，是精炼循环的典型失败。绝不要把明知有问题的东西交给评审者。
- 提交（Submit）：写入
<run>/round-<n>-submission.md：改了什么、涉及哪些文件；对每条先前发现，说明已修复/已反驳/已推迟及方式；以及一个Verify:部分——来自验证策略的、能证明你主张的确切命令或检查（评审者会运行它们）。 - 评审（Review）：生成新的评审智能体（Agent 工具，subagent_type: critic，run_in_background: false）：一个通用评审者，或每个视角一个、在单个并行批次中。绝不复用或对先前评审者使用 SendMessage——每轮一个全新实例才是关键。每个提示必须包含：
<run>/GOAL.md原文、轮次编号、其视角名称（如有），以及<run>/round-<n>-submission.md和所有已接受的先前裁决文件的路径（绝不含格式错误的）。不要包含你对工作的看法，也不要引导其批准。 - 记录（Record）：将每份报告逐字保存到
<run>/round-<n>-verdict.md，或按视角保存为<run>/round-<n>-verdict-<lens>.md。 - 分支（Branch）：
- 无论裁决如何，都要对每条 OUT-OF-LENS 行进行分诊——下一轮修复、反驳或在收尾时报告；绝不悄悄丢弃，即使所有视角都批准。
- 所有评审者
VERDICT: APPROVE→ 停止，进入收尾。 - 任一
VERDICT: REVISE→ 下一轮处理所有裁决中 BLOCKER/MAJOR 发现的并集（去重）；两个视角要求不兼容的改动 → 视为震荡保护：遵循目标契约的解读并标记。 - 格式错误的裁决（没有 VERDICT 行；REVISE 但无发现；有 BLOCKER/MAJOR 发现却 APPROVE；APPROVE 但 VERIFIED 行缺失或为空）→ 不接受；将其保存为
round-<n>-verdict[-<lens>]-malformed-<k>.md（k = 1, 2）而非第 4 步的路径，并在同一轮为该槽位重新生成一个全新评审者。同一槽位两次格式错误 → 停止并向用户呈现。 - 达到 max_rounds 仍未完全批准 → 停止，仍进入收尾。
收敛保护（每轮开始前按视角检查）
- 卡住（Stuck）：精确地说——你在第 n 轮提交中声称修复了某发现，而第 n 轮裁决仍报告同一缺陷（它现已出现在第 n-1 和第 n 两轮裁决中）→ 在开始第 n+1 轮前停止并向用户呈现；第二次相同修复尝试是浪费。
- 震荡（Oscillation）：新评审者要求撤销先前裁决要求的改动 → 不要来回摇摆：遵循目标契约的解读，在下次提交中记录冲突，并在收尾时标记。
- 反驳（Rebuttal）：绝不悄悄忽略你认为错误的发现——在下次提交中用证据反驳，让下一位评审者裁决。一旦被反驳且无新证据地再次主张，则交给用户，而不是再来一轮。
反作弊规则
- 第 1 轮后绝不编辑
<run>/GOAL.md来让目标变简单，也绝不在运行中途删除视角来让批准变容易。若确实必须更改，需获得用户确认。 - 绝不把发现总结得比书面更有利——裁决文件是事实来源。
- 你提供的 Verify 命令必须是真实的——绝不把评审者指向你知道会通过的子集。
适用场景
- 初稿质量不足、目标可客观检验的代码、文档、设计、研究等交付物。
- 需要多视角（如安全、文风清晰度、API 设计）并行审查的工作。
- 需要可审计的迭代轨迹与逐轮裁决记录的场景。
限制
- 交付物必须以文件形式落地，评审者只能审查文件。
- 任务过于琐碎或标准纯属个人品味时，循环收益不足，协议要求直接说明并改为直接完成。
- 默认最大轮数为 5，达到上限仍未完全批准则停止并进入收尾。
- 同一槽位两次格式错误会停止并向用户呈现。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。