メニュー
在声称工作完成、已修复或通过之前使用，在提交或创建 PR 之前——要求运行验证命令并确认输出后才能做出任何成功声明；始终证据先于断言
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | verification-before-completion |
| description | 在声称工作完成、已修复或通过之前使用，在提交或创建 PR 之前——要求运行验证命令并确认输出后才能做出任何成功声明；始终证据先于断言 |
在没有验证的情况下声称工作完成是不诚实，而非高效。
核心原则： 始终证据先于声明。
违反此规则的字面意思就是违反此规则的精神。
没有新鲜的验证证据，不得声称完成
如果你在这条消息中没有运行验证命令，你就不能声称它通过了。
在声称任何状态或表达满意之前：
1. 识别：什么命令能证明此声明？
2. 运行：执行完整命令（新鲜的、完整的）
3. 阅读：完整输出，检查退出码，统计失败数
4. 验证：输出是否确认了声明？
- 如果否：用证据说明实际状态
- 如果是：附带证据做出声明
5. 然后才：做出声明
跳过任何步骤 = 说谎，而非验证
| 声明 | 需要 | 不充分 |
|---|---|---|
| 测试通过 | 测试命令输出：0 个失败 | 之前的运行、"应该会通过" |
| 检查器无错 | 检查器输出：0 个错误 | 部分检查、推断 |
| 构建成功 | 构建命令：exit 0 | 检查器通过、日志看起来不错 |
| Bug 已修复 | 测试原始症状：通过 | 代码改了、假定修复了 |
| 回归测试有效 | 红-绿循环已验证 | 测试通过了一次 |
| 代理完成了 | VCS diff 显示变更 | 代理报告"成功" |
| 需求满足 | 逐条清单核对 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "现在应该可以了" | 运行验证 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "检查器通过了" | 检查器 ≠ 编译器 |
| "代理说成功了" | 独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查就够了" | 部分什么都不证明 |
| "换个说法所以规则不适用" | 精神重于字面 |
测试：
✅ [运行测试命令] [看到：34/34 通过] "所有测试通过"
❌ "现在应该通过了" / "看起来正确"
回归测试（TDD 红-绿）：
✅ 写 → 运行（通过）→ 撤销修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我写了回归测试"（没有红-绿验证）
构建：
✅ [运行构建] [看到：exit 0] "构建通过"
❌ "检查器通过了"（检查器不检查编译）
需求：
✅ 重新阅读计划 → 创建清单 → 逐项验证 → 报告缺口或完成
❌ "测试通过了，阶段完成"
代理委派：
✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任代理报告
来自 24 次失败记忆：
始终在以下之前：
规则适用于：
验证没有捷径。
运行命令。阅读输出。然后声明结果。
这不可协商。
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
在实现完成、测试通过后，引导决定如何集成工作——提供合并、PR 或清理的结构化选项