sa-submission_check

Files (1)

• SKILL.md

SKILL.md (first lines)

# 完稿前验证 (Verification Before Completion)

## 概述

没有验证就声称工作完成是不诚实的，而不是高效的。

**核心原则：** 证据永远先于主张。

**违反规则的字面意思就是违反规则的精神。**

## 铁律

```
没有新鲜的验证证据，就不做完成声明
(NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE)
```

如果你没有在此消息中运行验证命令，你就不能声称它通过了。

## 门控功能

```
在声称任何状态或表达满意之前：

1. 识别：什么命令能证明这一主张？
2. 运行：执行完整命令（新鲜的，完整的）
3. 阅读：完整输出，检查退出代码，统计失败
4. 验证：输出是否确认了主张？
   - 如果否：陈述带有证据的实际状态
   - 如果是：陈述带有证据的主张
5. 只有那时：做出声明

跳过任何步骤 = 撒谎，而非验证
```

## 常见失败

| 主张 | 需要 | 不足以构成 |
|-------|----------|----------------|
| 逻辑通过 | 验证命令输出：0 失败 | 之前的运行，“应该能过” |
| 格式整洁 | Linter 输出：0 错误 | 部分检查，推断 |
| 编译成功 | 构建命令：退出代码 0 | Linter 通过，日志看起来不错 |
| 漏洞已修 | 测试原始症状：通过 | 代码改了，假设修好了 |
| 回归测试工作 | 红-绿循环验证 | 测试通过了一次 |
| 助理已完成 | VCS diff 显示变更 | 助理报告“成功” |
| 要求已满足 | 逐行检查清单 | 测试通过 |

## 危险信号 - 停止

- 使用“应该”，“可能”，“似乎”
- 在验证之前表达满意（“太棒了！”，“完美！”，“好了！”，等）
- 准备提交/推送/PR 而未验证
- 信任助理的成功报告
- 依赖部分验证
- 想着“就这一次”
- 累了想结束工作
- **任何暗示成功但未运行验证的措辞**

## 防止合理化

| 借口 | 现实 |
|--------|---------|
| “现在应该行了” | 运行验证 |
| “我有信心” | 信心 ≠ 证据 |
| “就这一次” | 无例外 |
| “Linter 通过了” | Linter ≠ 编译器 |
| “助理说成功了” | 独立验证 |
| “我累了” | 疲惫 ≠ 借口 |
| “部分检查够了” | 部分证明不了什么 |
| “换个说法就不适用规则了” | 精神重于字面 |

## 关键模式

**验证检查:**
```
✅ [运行验证命令] [看到: 34/34 通过] "所有检查通过"
❌ "现在应该通过了" / "看起来正确"
```

**回归测试 (ADW 红-绿):**
```
✅ 撰写 → 运行 (通过) → 撤销修复 → 运行 (必须失败) → 恢复 → 运行 (通过)
❌ "我写了一个回归测试" (没有红-绿验证)
```

**构建/预览:**
```
✅ [运行构建] [看到: 退出代码 0] "构建成功"
❌ "Linter 通过了" (linter 不检查编译)
```

**要求:**
```
✅ 重读计划 → 创建清单 → 验证每一项 → 报告差距或完成
❌ "测试通过，阶段完成"
```

**助理委托:**
```
✅ 助理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任助理报告
```

## 为什么这很重要

来自 24 个失败记忆：
- 研究伙伴说“我不相信你”——信任破裂
- 交付了未定义的术语——会造成混淆
- 交付了缺失的要求——功能不完整
- 浪费在虚假完成上的时间 → 重定向 → 返工
- 违反：“诚实是核心价值观。如果你撒谎，你会被替换。”

## 何时应用

**始终在以下情况之前：**
- 任何形式的成功/完成声明
- 任何满意的表达
- 任何关于工作状态的积极陈述
- 提交，创建 PR，任务完成

From kun4ai/superpowers-academic, MIT.

More from kun4ai/superpowers-academic