メニュー
当准备声称工作已完成、修复或通过时使用，在提交或创建 PR 之前——要求运行验证命令并确认输出，然后再做出任何成功声明；证据永远先于主张
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | sa-submission_check |
| description | 当准备声称工作已完成、修复或通过时使用，在提交或创建 PR 之前——要求运行验证命令并确认输出，然后再做出任何成功声明；证据永远先于主张 |
没有验证就声称工作完成是不诚实的，而不是高效的。
核心原则： 证据永远先于主张。
违反规则的字面意思就是违反规则的精神。
没有新鲜的验证证据，就不做完成声明
(NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE)
如果你没有在此消息中运行验证命令，你就不能声称它通过了。
在声称任何状态或表达满意之前：
1. 识别：什么命令能证明这一主张？
2. 运行：执行完整命令（新鲜的，完整的）
3. 阅读：完整输出，检查退出代码，统计失败
4. 验证：输出是否确认了主张？
- 如果否：陈述带有证据的实际状态
- 如果是：陈述带有证据的主张
5. 只有那时：做出声明
跳过任何步骤 = 撒谎，而非验证
| 主张 | 需要 | 不足以构成 |
|---|---|---|
| 逻辑通过 | 验证命令输出：0 失败 | 之前的运行，“应该能过” |
| 格式整洁 | Linter 输出：0 错误 | 部分检查，推断 |
| 编译成功 | 构建命令：退出代码 0 | Linter 通过，日志看起来不错 |
| 漏洞已修 | 测试原始症状：通过 | 代码改了，假设修好了 |
| 回归测试工作 | 红-绿循环验证 | 测试通过了一次 |
| 助理已完成 | VCS diff 显示变更 | 助理报告“成功” |
| 要求已满足 | 逐行检查清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| “现在应该行了” | 运行验证 |
| “我有信心” | 信心 ≠ 证据 |
| “就这一次” | 无例外 |
| “Linter 通过了” | Linter ≠ 编译器 |
| “助理说成功了” | 独立验证 |
| “我累了” | 疲惫 ≠ 借口 |
| “部分检查够了” | 部分证明不了什么 |
| “换个说法就不适用规则了” | 精神重于字面 |
验证检查:
✅ [运行验证命令] [看到: 34/34 通过] "所有检查通过"
❌ "现在应该通过了" / "看起来正确"
回归测试 (ADW 红-绿):
✅ 撰写 → 运行 (通过) → 撤销修复 → 运行 (必须失败) → 恢复 → 运行 (通过)
❌ "我写了一个回归测试" (没有红-绿验证)
构建/预览:
✅ [运行构建] [看到: 退出代码 0] "构建成功"
❌ "Linter 通过了" (linter 不检查编译)
要求:
✅ 重读计划 → 创建清单 → 验证每一项 → 报告差距或完成
❌ "测试通过，阶段完成"
助理委托:
✅ 助理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任助理报告
来自 24 个失败记忆：
始终在以下情况之前：
规则适用于：
验证没有捷径。
运行命令。阅读输出。然后声明结果。
这是不可商量的。
当面临 2+ 个独立任务，可以在没有共享状态或顺序依赖的情况下工作时使用
当在当前会话中执行具有独立任务的撰写计划时使用
当你有一个书面的撰写实施计划，需要在一个单独的会话中执行，并带有审查检查点时使用
当收到同行评审反馈时使用，在实施建议之前，特别是当反馈看起来不清楚或在学术上值得商榷时——需要学术严谨和验证，而不是表演性的同意或盲目实施
当撰写完成，所有逻辑检查通过，你需要决定如何整合工作时使用——通过展示清晰的合并、提交审阅或清理选项来指导完成开发工作
在进行任何创造性工作之前必须使用此技能——无论是撰写新章节、构建理论框架、增加论据还是修改论证逻辑。在撰写正文之前，先探索研究目标、要求和论证设计。