القائمة
在声称工作完成、已修复或通过之前使用，在提交或创建 PR 之前——要求运行验证命令并确认输出后才能做出任何成功声明；始终证据先于断言
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
在实现完成、测试通过后，引导决定如何集成工作——提供合并、PR 或清理的结构化选项
| 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 次失败记忆：
始终在以下之前：
规则适用于：
验证没有捷径。
运行命令。阅读输出。然后声明结果。
这不可协商。