用途 该技能用于约束开发流程中的“完成”判定：代码看起来正确不算验证，任何变更都必须有可观察的实证证据，才能标记为完成。它针对的是一种常见失败模式——用“应该可以了”“之前类似改动能跑”“按我的理解没问题”等说法代替实际验证。
主要能力 按变更类型规定必选的验证方式与工具：
- UI 变更：用 browser_subagent 截图，展示预期视觉状态。
- API 端点：用 run_command 执行命令，展示正确响应。
- 构建/配置：用 run_command 展示构建或测试成功输出。
- 数据变更：用 run_command 执行查询，展示预期数据状态。
- 文件操作：用 run_command 做文件列表或内容验证。
使用方式 在标记任何任务“完成”之前，按四步协议执行：
- 确定验证标准：这次变更后什么应当为真，如何观察。
- 执行验证：运行相应命令或操作，捕获输出/证据。
- 记录证据：写入 .gsd/JOURNAL.md 对应任务下，记录实际输出，而非只写“通过”。
- 对照标准确认：证据是否符合预期结果；不符合则任务未完成。
文档给出的示例包括：用 curl 请求 API 并展示返回 JSON；用浏览器工具进入 /dashboard 截图并确认头部、数据与布局；运行 npm run build 并展示成功编译输出。反例则是只声明“端点可用”“组件应能正确渲染”“构建现在应该没问题”。
禁用表述 不得以下列说法作为完成依据：“This should work”“The code looks correct”“I've made similar changes before”“Based on my understanding”“It follows the pattern”。
集成与失败处理 该技能与 /verify 工作流、/execute（标记任务完成前必须验证）以及 GEMINI.md 中的 Rule 4（实证验证强制执行）集成。验证失败时：不得标记任务完成；在 .gsd/STATE.md 记录失败；若原因已知则创建修复任务；连续失败 3 次以上时触发 Context Health Monitor。
适用场景 适用于需要严格控制完成质量的编码与交付流程，尤其涉及界面、接口、构建配置、数据和文件操作的变更。
限制 资料未提供具体安装命令、支持的平台范围、版本要求或更多配置项，暂未提供。