用途：review-tests 只回答一个问题——给定这段 diff，现有测试是否足以捕获细心读者会担心的 bug。它不判断测试是否存在（那是 test-gate 的职责），也不判断测试是否通过。它与 /code-review 并列组合而非嵌套：/code-review 回答 Standards 与 Spec，/review-tests 回答 Tests。
主要能力：按五个部分输出发现，每条发现带 ID、引用 file:line 并摘录相关代码或测试行。M1 未测试分支（新条件、switch、多态分派、提前返回、守卫子句）；M2 未测试错误路径（新 throw、被拒 promise、校验失败、异常处理器）；M3 未测试公共契约变更（签名、返回类型、schema、CLI 标志、环境变量、HTTP 响应）；M4 未测试集成面（网络调用、数据库写入、文件 I/O、IPC、消息队列、第三方 SDK）；C 为较低置信度的判断项（并发、顺序、幂等、部分失败、相邻代码回归、性能悬崖）。空部分跳过，不填充，报告控制在 600 词以内。
使用方式：先固定基准点（SHA、分支、tag、main、HEAD~5，未指定则询问），捕获 git diff <fp>...HEAD 与 git log <fp>..HEAD --oneline；若本会话已运行 /code-review，需核对基准点一致。再按顺序识别 spec 来源：提交信息中的 Closes #N / Fixes #N、用户传入路径、docs/、specs/ 或 .scratch/ 下匹配分支名的 PRD 或 spec；找不到则询问，若确认没有则注明“no spec; reviewing against the diff alone”。随后启动一个 general-purpose 子代理，传入 diff 命令、提交列表、spec 内容与固定简报，由其通过 grep 函数与模块名定位测试，而非依赖文件名约定。最后在 ## Tests 标题下按五个子标题呈现，结尾一行给出各部分发现数与最高置信度的 Missing 项。
适用场景：需要评估某次改动测试覆盖是否充分、且希望与代码审查并行阅读时。
限制：只读，不写测试、不改生产代码、不运行测试套件、不消费或改写 /code-review 输出、不做 AST 或覆盖率工具推断。若 diff 无可执行代码（文档、配置、仅 schema），M1-M4 可合法为空。报告后可建议后续步骤但不自动执行：M1-M4 可经 /to-issues 立项再由 /afk-cook 补测；C 类应交给 /diagnosing-bugs 作为 Phase-1 种子构造复现。该技能为 memo-flow 原创，与上游 vendored 的 /code-review 并存；若上游日后为 /code-review 增加 Tests 轴，本技能将退役。