用途：该技能用于在宣称实现完成、创建 PR 或提交交付物之前强制进行技术验证，把“看起来正确”与“已验证可用”区分开。
主要能力：提出“铁律”——没有失败测试不写实现，没有证据不下完成结论，没有理解不写代码；规定 RED（先写失败测试）、GREEN（最小实现通过测试）、REFACTOR（不改变行为地改进）的 TDD 循环；提供验证协议：复现问题、在当前环境测试方案、排查已知问题与边界情况、捕获证据、证明完成；要求覆盖行、分支与变异覆盖率门槛；引入“智能体报告是主张而非证据”，工作流脚本只作门禁输入，证据须在可粘贴输出的地方产生。
使用方式：在说“完成”“就绪”或建议某个配置“应该可用”之前使用。按步骤用 ps、echo、cat 等命令检查进程、环境变量和配置文件，记录失败输出与错误日志，执行方案并比对实际输出，查阅 GitHub issues、版本兼容性与官方文档，记录命令、输出、时间戳和结论，最后逐项验证验收标准。支持模块包括 TodoWrite 命名规范、证据日志、独立验证与验证器完整性。
适用场景：实现完成声明、创建 PR、提交评审、验证 LSP 等配置是否真正生效、评估改进工作流（如 /update-plugins、/fix-workflow）的量化影响。
限制：不用于实现前的规划（应使用 imbue:karpathy-principles）和判断工作是否在范围内（应使用 imbue:scope-guard）。若无法逐行解释配置或说明某实践为何适用，说明验证步骤已被跳过。资料未提供具体价格、收费或平台支持信息。