用途：对 Strikethroo 计划的累计 diff 做独立第二执行环境审查，运行环境与写代码的环境不同。<root> 为调度提供的工作区根目录。审查发现只被记录，不被应用，由实现者阅读后决定如何处理，因此每条发现应凭证据成立，而非为通过筛选而写。
主要能力与规则：先读 <root>/config/shared/anti-rationalization.md，其中列出需要避免的借口，例如“理论上可能失败”必须给出具体输入或状态；“计划没写但应该写”不属于审查范围，只检查是否符合计划明确要求；设计意见不记录；不确定应降低 confidence 而非堆砌篇幅；未读的调用方属于假设，需读取或标注 confidence="medium" 并说明；严重度代表影响，不得夸大；无发现是有效结果，不得为凑数制造发现。
输出：生成一个 urn:self-review:v2 命名空间的文档，需通过 <root>/config/schemas/self-review-v2.xsd 校验。每个变更文件都要有独立 <file> 元素，包括读过但无意见的文件，路径为仓库相对路径。每条评论只给一对行号：新增或上下文行用 new-line-，删除行用 old-line-，文件级评论两者都不给，单行时 start 等于 end。输出前先读 references/review-example.xml.md。禁止输出 <suggestion>，该元素供人类审查者提供逐字替换文本，非人类审查者应在 <body> 中描述修复方式。
操作流程：读 <root>/config/hooks/CODE_REVIEW.md，其权威性高于本提示；完整读计划，记录该 diff 对应的明确需求；用 git diff <base> 对比基线提交与当前工作树，不要用 <base>..HEAD，以免漏掉未提交改动，完整读 diff，只运行一次；做影响范围检查，对 diff 中重命名、改签名、删除或改变行为的符号，搜索仓库并读取 diff 外的每个调用点，调用点若收到不同形状、参数数量或错误契约即为缺陷；对候选逐条评判，只归入 requirement-conformance 或 defect 两类，否则丢弃，并给出文件、行范围和具体触发输入或状态，追溯到需求或代码本身展示的缺陷，按第一步的 hook 评定严重度和置信度，不附 <suggestion>；生成文档；报告发现总数及各严重度数量。
范围外：不记录推测性加固，不记录计划未要求的测试，不因“抽象不对”而扩大范围。失败模式：无法读计划则停止并报告，不得凭重建需求审查；空 diff 则输出无子元素的 <review> 并报告零发现，视为成功；发现不符合 schema 时修正发现形状而非 schema；想自行应用修复时应停止，检测与修复按设计走不同路径。
限制：资料未提供具体安装命令、收费、平台支持或效果数据。