| name | verifying-before-completion |
| description | Use when about to declare an implementation, fix, or quality-gate run complete — run a fresh build/test/lint verification command in the same turn and read its output before stating success. |
| origin | rune |
Verifying Before Completion
声明完成前的横切诚信门。任何即将"宣称完成 / 通过 / 已修 / 正常工作"的时刻，必须在当前消息内跑过验证命令并读完输出。
启动时公告： "使用 verifying-before-completion skill 跑验证命令。"
核心原则： Evidence before claims, always.
铁律
没有在当前消息内跑过验证命令 → 不许声称该项通过
违反字面就是违反精神。这条不与 IRON LAW L1/L3 并列，而是 L3 "未通过审查的代码不许 commit" 的前置补强 —— L3 守 commit 时点，本 skill 守 commit 之前的每个 claim 时点。
触发场景
任何即将打出以下措辞之前，必须先 invoke 本 skill：
- "测试通过 / tests pass / passing"
- "build 成功 / build succeeds"
- "lint clean / no errors"
- "bug 修好 / fix works / 已修复"
- "完成 / done / finished"
- "通过 / 验证通过 / 已验证"
- "看起来对 / 应该过 / should work / looks correct"
以及以下流程节点（钩子触发）：
| 节点 | 验证内容 |
|---|
investigate 4b GREEN 后 | 当前消息内跑原复现测试，确认 PASS |
investigate 4c IMPROVE 后 | 当前消息内重跑 RED→GREEN 测试套件，确认未回归 |
investigate 4f 回 4d 之前 | 当前消息内跑复现测试 + 每层防御独立测试 |
code-quality-gate 通过声明前 | 当前消息内有 lint/format/typecheck 完整输出 |
| 接收 subagent DONE 报告时 | git diff 看实际改动 + 跑相关测试（详见下文 Subagent 场景） |
| commit / push / PR 创建前 | 全量测试套件 + 覆盖率（与 commit-quality 串联，详见下文） |
Gate 函数（声明前 5 步）
1. IDENTIFY — 什么命令能证明这个声明？
2. RUN — 在当前消息内执行完整命令（禁止复用历史输出）
3. READ — 读完整 output、检查 exit code、清点 failure 数
4. VERIFY — output 是否真的支持该声明？
├─ 不支持 → 报告实际状态（附 evidence）
└─ 支持 → 带 evidence 做声明
5. CLAIM — 才允许说 "done / pass / 修好了"
跳过任一步 = 撒谎，不是验证。
声明 vs evidence 对照
| 声明 | 必备 evidence | 不够 |
|---|
| 测试通过 | 测试命令完整 output + 0 failures | 历史运行 / "应该过" |
| Lint 干净 | linter 当前 output + 0 errors | 部分检查 / 推断 |
| Build 成功 | build 命令 + exit 0 | "linter 过了" |
| Bug 修好 | 原 bug 复现路径测试 PASS | 改了代码就假设 |
| 回归测试有效 | red-green 双向验证（revert fix → fail → restore → pass） | 跑一次就过 |
| Subagent 完成 | git diff 看实际改动 + 测试 fresh PASS | subagent 自报 success |
| 需求满足 | 逐条 checklist 验证 | 测试整体过了 |
Red Flags — 出现立刻停
- 说 "should / probably / seems to / 应该 / 大概 / 看起来"
- 跑命令前已经在打"完成感"措辞（"很好""完美""done""搞定"）
- 准备 commit / push / PR 但当前消息没验证 output
- 信任 subagent 自报 success 不去 diff
- "局部检查就够 / 只是这次跳过"
- 累了想结束
反 rationalization
| 借口 | 现实 |
|---|
| "应该过了" | RUN 命令 |
| "我有信心" | 信心 ≠ evidence |
| "就这一次" | 没有例外 |
| "linter 过了 = 编译过了" | linter 不查编译 |
| "subagent 说成功" | 独立验证 diff |
| "累了" | 累 ≠ 借口 |
| "局部检查够用" | 局部不能证明整体 |
| "措辞不一样规则不适用" | 精神高于字面 |
| "我已经手动测过了" | 手动测试无记录、不可重放、不算 evidence |
Subagent 场景的推荐补强
触发条件： 主代理接收 implementer/reviewer subagent 的 DONE/APPROVE 报告，且即将基于该报告进入下一流程节点（如 SDD Step 2/3、Phase 6 收尾）时。
推荐补强（非硬改 SDD 控制流）：
git diff <base_SHA>..<head_SHA> —— 确认 subagent 真改了它声称改的文件- 跑 subagent 应该已经跑过的测试命令 —— 不复用 subagent 的 output
- 如果 diff 为空或与报告不符 → 视为 BLOCK，要求 subagent 重新执行（与 SDD 既有 BLOCKED 状态处理一致）
这条是 SDD "trust but verify" 原则的横切补强建议，不修改 SDD 流程控制本身。SDD skill 中既有的 Step 1 状态处理（DONE/BLOCKED/NEEDS_CONTEXT）保持原样；本节为主代理在收到 DONE 时提供推荐的 verify 动作清单。
与既有 skill 的边界
code-quality-gate：跑命令本身被该 skill 包装；本 skill 要求的是"宣称 quality-gate 通过前必须有 fresh 命令输出"code-review：reviewer subagent 报 APPROVE 后，主代理仍需 verify reviewer 真看了 diff（看 reviewer 报告里有没有引用具体 file:line），而非盲信 verdictcommit-quality：负责 commit 前 lint staged 文件 + secrets 扫描；本 skill 补强其前序步骤——commit-quality 触发前必须已有全量测试 PASS 输出作为 evidence（fresh 输出，不复用历史）code-quality-gate vs commit-quality：前者按文件改动后触发（任务内的 lint/format/typecheck），后者按 commit 前触发（staged-only lint + secrets）；本 skill 在两者之间作为诚信门串联使用
Bottom Line
跑命令 → 读输出 → 然后才声明。
This is non-negotiable.
