review-it

审查

1. 固定范围

运行受影响的检查，提交所有内容（包括新文件），获取目标分支，并固定 <merge-base with origin/<target>>..HEAD。审查期间 HEAD 保持不变。

将目标分支合并或变基到待审查分支不会更改任何待审查代码，因此当 PR 自身的改动未变时，无需重新审查；land-it 会通过比较树来检查这一点。只有 PR 自身的改动发生变化时，才重新审查。

写下意图和验收标准，包括仅限聊天的标准，以及编写这项改动的模型系列，包括委派的工作者。确定 write-pr 的 Visible: 值：当改动会改变用户能看到或使用的屏幕时，设为 yes。若为 yes，现在就从固定的 HEAD 获取 write-pr 的截图，以便审查者据此评判。视频只录制一次，在修复完成后，于最终合并的 HEAD 上录制。

2. 定级

• skip：仅涉及文档、注释或文案；没有会运行的代码，也没有 Agent 指令。
• high：你能说出具体风险：差异会改变身份验证、权限、付款、机密信息、迁移或存储数据的行为，或者以无法通过回滚撤销的方式改变公共契约或存储格式。若这些领域中的文件行为保持不变，则不构成风险。
• standard：其他所有改动，无论涉及多少文件或子系统。

除非你能指出 high 风险，否则定级为 standard。用户给出的等级是最低等级。skip 直接进入回执。等级决定审查投入；决定 land-it 是否在未经用户确认的情况下合并的，是 write-pr 的 Door 行，而非等级。无法通过回滚撤销的 high 风险会使 PR 的状态变为 Door: one-way。

3. 审查

在固定范围上运行一次 interrogate：按照 pstack-models.md 的 interrogate reviewers 行，使用 t3-capacity 解析后，安排两名审查者并行工作；从主导模型未编写这项改动的席位开始，每个席位在模型容量不足时依次尝试其后备模型。standard 使用 high 运行审查者，high 使用 xhigh。每份简报都必须包含意图和验收标准、固定范围、审查简报的绝对路径、工作树、任何规范、问题和仓库指令文件的路径，以及 Visible: 值；若审查者发现改动会改变用户能看到或使用的屏幕，而 Visible: 值却为 no，则应将其报告为一项发现。若为 yes，每份简报还必须包含演示内容的路径，以及用户批准的原型（如有），并要求审查者以用户的视角评判演示，使用已安装的设计技能（例如 frontend-design 和 emil-design-eng）：演示是否符合原型，是否存在多余、缺失或错位的元素、不均匀的间距、用户不需要的文字，或看起来有问题的状态。Act On 中的发现就是要处理的发现；不予采纳的 Consider 发现应标记为 rejected 并说明原因，以便回执记录每一处分歧。已驳回项是审查者自行驳回的内容，不计入任何类别。

通过 delegate_task 为每位审查者安排任务，运行时模式使用 full-access，并提供只读简报：无头运行时无人能批准该任务。当该行中的所有模型都达到容量上限时，报告阻塞项。若 delegate_task 不可用（例如在子 Agent 中出现 parent_not_active），则将固定范围交还父级并报告为阻塞项。安排完毕后结束本轮；完成通知会唤醒你。

审查者对固定的 HEAD 返回实质性结论后，该次审查才计为完成；对拒绝、配额错误和空结果重新安排审查。按照 ~/.agents/skills/poteto-mode/references/t3-execution.md 的说明，监控每个 Grok 席位是否出现_停滞_运行：停滞席位给出的最终结论计为其审查结果。若某项发现指出具体的 high 风险，则在回执中将等级提高到 high；无需增加审查轮次。若某项发现指出无法通过回滚撤销的风险，则将 Door: one-way 设为必需项，除非修复消除了该风险。

4. 修复

验证并去重各项发现，然后批量应用有效且属于范围内的发现，包括结构性简化。自行决定这些发现引出的问题，并在 PR 的 What and why 中记录选择。需要采用新设计或让差异大致翻倍的修复应转为后续议题，并以 follow-up #<issue> 为由拒绝，除非它是此差异中的正确性或安全漏洞。 重新运行受影响的检查并提交。如果修复更改了用户可见的屏幕，只重新截取受影响的屏幕截图，并自行对照各项发现进行检查。然后，在需要时，从最终 HEAD 录制 write-pr 的视频：用户批准的是最终合并的那个 HEAD 的演示。

根据对应的发现自行检查每项修复并提交。只有当修复更改了发现中未提及的行为时，才运行确认审查：从 interrogate reviewers 行中选一位新的 high 级审查者，最好是未编写这些修复的审查者；该审查者只阅读修复范围（上次审查的 HEAD 到新的 HEAD）以及此前的发现。应用、检查并提交其有效发现。完成这一次确认审查后，仍未修复的正确性和安全性发现计为 open 并交给用户。一个 PR 只进行一次完整审查；确认审查只阅读修复。

5. 回执

返回此行，供 write-pr 的 Review 部分使用，并附上任何阻碍项及其后续步骤。land-it 会解析此行，因此请保持其格式完全一致。rejected 统计审查者提出且作者拒绝的发现；open 统计交给用户的发现、阻碍项以及未返回结论的审查席位；reviewed 列出审查轮次看到的基础分支和 HEAD；若未进行确认审查，则列出根据其发现检查过修复后的 HEAD：

**Review.** <skip | standard | high> by <models>; <n> fixed, <n> rejected, <n> open; reviewed <short SHA> on <base branch>

在其下方，为每项被拒绝的发现各写一行：

- Declined: <finding> (raised by <model>): <specific reason>

列出提出该发现的每个模型。若两位审查者都提出了同一发现，则不能拒绝：必须修复，否则该发现将保持 open。如果它不是正确性或安全性漏洞，可以交由后续议题处理，理由为 follow-up #<issue>。