用途：在进入实现之前，对已有书面产物（故事、计划、验收标准、规格、设计稿）做对抗式审查，系统性地暴露“没写下来”的东西——缺失状态、未处理的边界情况、未声明的假设、不可验证的表述，以及仍然过大或横切的切片。理念是：上线后的故障多来自从未写下的内容，而非写错的内容，此时修复成本最低。
主要能力：提供计划、验收标准、设计稿三类清单。计划方面检查范围与意图、前置依赖、切片与回滚、失败与恢复、状态与数据、可观测性、安全合规、测试策略、隐性知识；验收标准方面检查可测量性、前置/触发/结果结构、负面路径、输入边界、时区与本地化、角色、非功能要求、可观测性、完成定义；设计稿方面检查加载、空态、部分、错误、成功、禁用、只读、离线、限流、过期等状态，以及内容长度、交互状态、响应式、无障碍、主题、权限、生命周期、国际化。
使用方式：先按清单“勘察”并静默记录候选缺口，再分为 Blocker、Should-address、Nice-to-have 三级；开环时说明审查的产物类型、各严重度数量与缺口最多的部分，取得用户同意后开始。之后一次只问一个问题，从 Blocker 开始，答案含糊时追问到可测试为止，然后把答案转成具体产物更新（新验收标准、计划段落、命名界面状态），展示提议并确认，确认后写入源文件，每 3–5 个缺口做一次回顾，直到 Blocker 与 Should-address 全部关闭，或用户叫停（此时显式给出未解决缺口清单）。
适用场景：用户问“缺什么”“挑毛病”“收紧一下”；分享计划、规格、验收标准或设计稿请求审查；准备开始实现前的完整性检查；交接给其他团队前；事前复盘。可与相关技能配合：多张设计稿一起看时配合 storyboard，工作过大或横切时配合 story-splitting，缺口是现有代码未记录的行为时配合 characterisation-tests。
限制：需要有一份可审查的产物；它不从零发现整棵决策树，也不负责把大工作拆成子故事。若产物尚未写下，应改用 specification 或已安装的 grill-me；若问题是工作过大而非意图未定，应转向 story-splitting；若产物已足够清晰可实现，应转向 planning；若只是判断实现是否满足权威产物，应使用 acceptance-review。不得为显得有产出而编造缺口。具体安装方式与运行命令资料未提供。