菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when starting any creative work — creating features, components, or functionality, modifying behavior, or solving ambiguous problems — before design or implementation. Covers product discovery, competitive research, feature analysis, technical design, and capability spec writing. Applies to every project; routes to writing-plans (non-UI) or design-workflow (UI).
Use when finishing an edit to source files — runs format, typecheck, and console.log detection before moving to the next task.
Use when implementation of a bug fix or feature task is complete — dispatches the appropriate language and global reviewers and returns a binary APPROVE/BLOCK verdict.
Use when about to git commit — validates commit message format, lints staged files, and scans staged content for secrets and debug artifacts.
Use when reaching the design-workflow V2-4 hard gate — adversarially reviews design artifacts (token coverage, contract completeness, artifact consistency, accessibility docs, responsive coverage, DESIGN.md compliance) against docs/designs/<feature>/ before development handoff.
Use when a task involves UI — new pages, components, visual interactions, or design tokens — including work in docs/designs/, *.pen files, or with Pencil MCP tools. Skip for backend-only, config-only, or refactoring without visual impact. Routes to writing-plans on completion.
| 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 skill 跑验证命令。"
核心原则： Evidence before claims, always.
没有在当前消息内跑过验证命令 → 不许声称该项通过
违反字面就是违反精神。这条不与 IRON LAW L1/L3 并列，而是 L3 "未通过审查的代码不许 commit" 的前置补强 —— L3 守 commit 时点，本 skill 守 commit 之前的每个 claim 时点。
任何即将打出以下措辞之前，必须先 invoke 本 skill：
以及以下流程节点（钩子触发）：
| 节点 | 验证内容 |
|---|---|
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 串联，详见下文） |
1. IDENTIFY — 什么命令能证明这个声明？
2. RUN — 在当前消息内执行完整命令（禁止复用历史输出）
3. READ — 读完整 output、检查 exit code、清点 failure 数
4. VERIFY — output 是否真的支持该声明？
├─ 不支持 → 报告实际状态（附 evidence）
└─ 支持 → 带 evidence 做声明
5. CLAIM — 才允许说 "done / pass / 修好了"
跳过任一步 = 撒谎，不是验证。
| 声明 | 必备 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 验证 | 测试整体过了 |
| 借口 | 现实 |
|---|---|
| "应该过了" | RUN 命令 |
| "我有信心" | 信心 ≠ evidence |
| "就这一次" | 没有例外 |
| "linter 过了 = 编译过了" | linter 不查编译 |
| "subagent 说成功" | 独立验证 diff |
| "累了" | 累 ≠ 借口 |
| "局部检查够用" | 局部不能证明整体 |
| "措辞不一样规则不适用" | 精神高于字面 |
| "我已经手动测过了" | 手动测试无记录、不可重放、不算 evidence |
触发条件： 主代理接收 implementer/reviewer subagent 的 DONE/APPROVE 报告，且即将基于该报告进入下一流程节点（如 SDD Step 2/3、Phase 6 收尾）时。
推荐补强（非硬改 SDD 控制流）：
git diff <base_SHA>..<head_SHA> —— 确认 subagent 真改了它声称改的文件这条是 SDD "trust but verify" 原则的横切补强建议，不修改 SDD 流程控制本身。SDD skill 中既有的 Step 1 状态处理（DONE/BLOCKED/NEEDS_CONTEXT）保持原样；本节为主代理在收到 DONE 时提供推荐的 verify 动作清单。
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 在两者之间作为诚信门串联使用跑命令 → 读输出 → 然后才声明。
This is non-negotiable.