独立评审（Independent Review）是一种用于代码变更评审的技能，其核心目标是让评审者在脱离作者上下文的干净环境中，以外部评审者的方式检查代码改动。编写代码的代理在实现过程中做了大量细小决策并逐一说服自己，继承该对话的评审者容易沿用相同推理、遗漏相同问题，因此该技能强调将评审者置于作者上下文之外。
用途方面，该技能适用于代理完成实现之后、合并之前，或当用户要求评审时，对代码变更进行独立检查。它也可作为MCode Engineering Notes 01《More subagents isn't better》的配套实践。
主要能力与使用方式包括四个步骤。第一步，向评审者只提供三样输入：代码差异（如 git diff <base>...HEAD 或已暂存的改动）、需求（变更应满足的 issue、spec、任务描述或验收标准）、测试结果（运行过的命令及真实输出，包括失败和跳过的测试）。不得传递作者的对话、计划、中间推理或自我评估；评审者回答的问题是“该变更是否满足需求”，而非“作者的推理是否成立”。若缺少需求，应停止并索要，因为无需求的评审只能检查风格。第二步，在全新上下文中运行评审，优先顺序为：仅带上述三样输入启动的子代理或任务（黑盒检查，边界清晰，结果紧凑）；若代理有内置评审命令或技能，则在新会话中启动；最后是在新会话中粘贴三样输入。评审应特别关注：代码依赖但未检查的假设（空输入、调用方“已校验”、顺序、并发、错误路径）、diff 未覆盖的需求项、通过但未真正验证需求的测试（同一代理编写的测试共享其盲点，应检查是否覆盖需求而非仅看是否通过）、超出声明范围的行为变化。第三步，以固定结构返回发现，每条发现须包含问题（一两句话说明错在哪）、位置（文件与行或函数）、原因（与需求或具体代码关联的出错理由）、严重程度（blocking / should-fix / nit）；缺少位置或原因的发现视为意见而非缺陷。第四步，回到主循环后不要全盘应用发现，应逐条打开所述位置的真实代码，最好用失败测试或具体输入确认问题存在，再行修复并重跑相关测试；同时记录被拒绝的发现及原因，避免下次评审重复提出。
适用场景为代理完成实现后、合并前的代码评审，以及用户主动要求评审时。限制方面，该技能要求必须提供需求，否则只能检查风格；评审输入需排除作者上下文；发现需经核实后才能修复。资料未提供具体的安装命令、平台支持、收费或价格信息。