self-review

用途

self-review 用于批判性地复查你最近的改动，并修复发现的问题。它根据改动规模选择两条路径之一；文档建议拿不准时就委派，因为成本低，而无偏见的阅读正是其价值所在。

适用于单个文件，或一个聚焦的修复或功能：以怀疑的眼光重读你的改动，关注正确性、完整性、回归、过度工程、不必要的冗长。然后直接修复发现的问题。

适用于跨多个文件、功能或修复的改动：委派给 critical-reviewer 子智能体，获得新鲜、无偏见的阅读，然后根据其报告采取行动。

新的审查者能发现你已经说服自己接受的问题，并把审查推理排除在你的上下文之外。

审查者是只读的，返回按优先级排序的发现（每条带严重级别和 file:line 位置）；你按严重程度分诊并应用修复。

委派时：

如果改动很大或很复杂，考虑用 fable 模型调用子智能体（如果可用），因为它是最强大的 AI 模型。
提供高信号简报。该智能体在本对话上下文之外运行。给它：改动文件列表（仅名称，例如 git diff --name-only）、你最初被要求做的任务以及范围内/范围外的内容、以及任何看起来有问题但实际是有意为之的地方。
只在独立的切片上并行。为每组互不交互的改动（按子系统、层或需求）生成一个审查者，并给每个审查者明确的边界——它负责的文件或区域——以免重叠。当切片共享接口或契约时，至少让一个审查者了解两侧，或使用单个审查者——只看到一侧的新审查者无法发现交互问题。不要为拆分而拆分。
默认保持新鲜。新的审查者提供无偏见的阅读，这正是自我审查值得做的原因。只有在审查确实需要本对话的细微差别时才 fork；绝不要为了对抗性阅读而 fork，因为 fork 会继承本智能体的偏见，从而失去意义。
用简洁的笔记写简报。关键词和要点，而非完整散文；审查者是有能力的模型，不是听众。
对于非常复杂的改动，选择最好的模型。如果要审查的工作非常复杂，使用可用的最强模型（例如 fable）；普通审查使用默认模型（opus）。

每个审查者智能体完成并返回其发现后（除非有充分理由等待所有发现，或另有指示）：

$ARGUMENTS