用途
本技能用于对代码库进行对抗式的生产就绪审查，判断其是否真正完成。它不信任计划、提交历史或测试通过率，只把代码、接线、配置和故障行为当作证据。核心任务是尝试证伪“工作已完成”，并报告哪些部分经受住了证伪。
主要能力
- 输入契约（Phase 0）：明确审查对象，一次性询问无法推断的信息，其余记录为范围限制。
- 确定性扫描（Phase 1）：运行捆绑的扫描脚本，报告不完整标记、吞掉的错误、调试残留、疑似密钥、路由与鉴权标记、配置与迁移产物、测试面、变更面等。输出是线索而非结论，需逐条在上下文中判断。
- 需求追溯矩阵（Phase 2）：从计划中提取需求与验收标准，赋予稳定 ID，并沿执行方向追溯至代码。状态只有三种：VERIFIED（附路径:行号及证明测试）、GAP（附空搜索证据）、UNVERIFIABLE（说明阻碍及解决条件，绝不计为完成）。
- 测试完整性（Phase 3）：不依赖测试数量或覆盖率。对三个最重要的 MUST 进行破坏性验证：反转条件或注释掉检查，确认测试失败，再恢复。检查负向用例、断言 mock 而非行为的测试、同义反复、变更行覆盖、跳过/隔离/重试测试。
- 影响范围（Phase 4）：对比基线，列出每个变更的公共函数、端点、模式、事件或配置键的现有消费者，检查是否仍成立。关注共享表列、迁移锁时长、契约兼容性、权限模型放宽。
- 非功能门禁（Phase 5）：参考 verification-checklists.md，覆盖安全、可靠性、可观测性、性能、数据/迁移、配置/部署/回滚。安全不是一条要点：每个新路由都需要在代码和测试中证明鉴权决策，多租户系统需跨租户测试验证隔离。
- 严重度评级：Critical（可被利用或破坏性）、High（重要需求未实现/未接线/不可达、主路径失败未处理、MUST 无测试、破坏性契约变更、设计故障模式无信号）、Medium（部分实现或证明薄弱）、Low（死代码、命名、外观债务）。
- 输出：使用 output-template.md，每个问题按严重度→需求→证据（路径:行号或命令输出）→问题→所需修复。修复需指明文件和具体行为。百分比必须附计数，如“实现完整性：68%（23/34 需求 VERIFIED；8 GAP，3 UNVERIFIABLE）”。裁决规则：任何 Critical 或 High 未关闭则 NO-SHIP，并说明翻转条件。所有“不存在”声明需附零命中搜索。
- 修复（Phase 6）：仅在审计输出后、且获授权时进行。按严重度顺序修复。每个子代理只处理一个问题，给定问题 ID、需求、证据、所需修复、可触碰文件、验收测试、约束。返回需包含 diff 摘要、变更文件、测试命令及真实输出、新 UNRESOLVED ASSUMPTION、观察到的爆炸半径。拒绝无测试输出的成功声明。每次修复后运行目标测试、全量测试，并重新审计受影响需求及其消费者。
使用方式
- 明确审查对象：仓库路径、分支/PR、基线引用、计划/PRD 版本、目标环境、测试/检查命令、是否授权修复及严重度上限。
- 运行扫描脚本：
bash ${CLAUDE_SKILL_DIR}/scripts/scan_repo.sh /path/to/repo --base origin/main > scan.md - 按 Phase 2-5 逐步执行，记录证据。
- 输出完整审计报告，再考虑修复。
- 修复时遵循子代理契约，保持问题 ID 稳定以便二次运行报告增量。
适用场景
- 代码库上线前的生产就绪审查。
- 对照 PRD 或实现计划验证完成度。
- 需要对抗式、证据驱动的审查，而非文档式审查。
- 多租户系统、有迁移或契约变更的项目。
限制
- 若无法运行测试套件，审查必须标记为文档审查。
- 无法验证的需求记为 UNVERIFIABLE，绝不计为完成。
- 修复需授权，且不得猜测产品决策或削弱失败测试。
- 遇到需要产品决策、需求变更、同一测试两次失败、爆炸半径超出审查范围、需要凭证或生产访问时，应停止并返回人工。
- 具体脚本内容、检查清单细节、输出模板未在资料中提供，暂未提供。