用途：回答“这些测试用例到底测得好不好”，对已有用例（祖传、他人编写、AI 产出）做事后、独立的审查，区别于写用例过程中的自审。
输入：已有用例文件（markmap + Schema，若无可先行抽取）、PRD/需求模型、代码仓库。输出：直接修订用例文件（修订后重新抽取 Schema），并在文件末尾追加审查记录，按 TC 编号列出缺失、冗余、错误、高风险未覆盖。
主要能力与工作流：一、建立可测点基准（分母），按人工标注清单、需求模型与用户确认清单、自行提炼（标注未经确认）的优先级取用，基准缺失时如实说明，不编造覆盖率。二、覆盖审查，执行 ../core/coverage.md 的核心 7 维逐项全检加横切可执行性，扩展维度按项目类型选取；状态流转维度加载 ../core/methods/state-machine.md 逐边核对；关注写入路径×校验规则、失败×重试、标识×重复等二阶交叉缺口。三、可执行性审查，执行 ../core/executability.md 全部检查项，逐条过八条硬标准。四、正确性审查（有 PRD/代码时），核对预期结果与规则/实现是否一致，检查优先级与风险等级对齐。五、修订与落盘，直接补缺失、删冗余、改错误断言、补可执行性要素，新增与改写用例执行 ../core/case-format.md 格式约束，修订后用 ../core/scripts/validate_schema.py 复验通过再落盘。六、交付修订后文件路径、审查记录摘要、基准可信度声明与遗留建议。
适用场景：审存量用例资产覆盖与可执行性；审 AI 产出用例；需要独立于编写者的审查结论。不适用：从零写用例（用 test-case-writing）、写时自审、代码变更后的回归范围选择（用 regression-testing）。
限制与注意：无基准不得直接评覆盖率；覆盖与可执行性须双线审查；只报问题不修订文件会导致报告与用例两张皮；审查记录应追加在用例文件末尾而非独立报告；修订用例同样须满足可执行性标准，避免引入占位符或代码内部。具体命令、脚本参数与格式细节以资料所述文件为准，其余暂未提供。