ワンクリックで
verification-before-completion
在准备声称工作已完成、已修复或已通过,且在提交或创建 PR 之前使用 - 需要先运行验证命令并确认输出,再做任何成功声明;涉及目标板或人工确认的固件改动,只能报告已实现或待人工验证
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
在准备声称工作已完成、已修复或已通过,且在提交或创建 PR 之前使用 - 需要先运行验证命令并确认输出,再做任何成功声明;涉及目标板或人工确认的固件改动,只能报告已实现或待人工验证
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
在当前会话里按已写好的实现计划顺序执行任务时使用
在已有规格或多步骤任务需求、且在动代码之前使用。若上游 ddev-pc-test 已产出测试用例,自动走 TDD 流程:先实现测试 demo 代码(红灯),再实现被测代码(绿灯),测试覆盖不到的部分直接开发。
文档审查技能。将文档审查任务派发给独立子代理,重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误,以及 AI 实现过程中产生的决策记录(implementation-notes.md)。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下,spec 文档确认后,需要继续以图优先方式梳理结构体定义、数据流和流程时使用
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用(仅限代码改动场景,非项目级架构文档初始化)
在代码实现完成后、准备结束任务或进入发布前使用,用来核对代码实现是否与 spec 文档以及 detail 文档一致,并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论
| name | verification-before-completion |
| description | 在准备声称工作已完成、已修复或已通过,且在提交或创建 PR 之前使用 - 需要先运行验证命令并确认输出,再做任何成功声明;涉及目标板或人工确认的固件改动,只能报告已实现或待人工验证 |
没有验证就宣称工作完成,属于不诚实的交付。
核心原则: 先有证据,再下结论,始终如此。
只遵守字面而违背精神,本质上还是违反这条规则。
如果结论依赖后者,AI 只能说明“已实现”或“待人工验证”,不能替人宣布通过。
没有新的验证证据,就不能宣称完成
如果你没有在这条消息里运行验证命令,就不能说它通过了。
在宣称任何状态、或者表达满意之前:
1. 识别:哪条命令能证明这个结论?
2. 运行:执行完整命令(全新、完整地跑一遍)
3. 读取:看完整输出,检查退出码,统计失败数
4. 验证:输出是否真的证明了这个结论?
- 如果否:用证据说明真实状态
- 如果是:带着证据再下结论
- 如果结论依赖目标板/人工确认:必须有现场或人工证据;没有就只能降级成“已实现,待人工验证”
5. 只有这之后:才能做出结论
少一步都不能算验证,只是在伪造把握。
| 结论 | 需要 | 这些不够 |
|---|---|---|
| 测试通过 | 测试命令输出:0 个失败 | 之前的运行结果,“应该能过” |
| 代码检查通过 | 代码检查输出:0 个错误 | 局部检查、推断 |
| 构建成功 | 构建命令:退出码 0 | 代码检查通过、日志看起来没问题 |
| bug 已修复 | 原始症状对应的测试通过 | 只是改了代码,假设它好了 |
| 回归测试有效 | 已验证红绿循环 | 测试只通过一次 |
| 代理已完成 | VCS diff 显示了改动 | 代理自己说“成功” |
| 满足需求 | 逐条清单已核对 | 测试通过 |
| 硬件相关改动已完成 | 目标板刷写、人工观察、测量记录 | 只有 host 构建/测试通过 |
| 借口 | 现实 |
|---|---|
| “现在应该能用了” | 去跑验证 |
| “我很有把握” | 有把握 ≠ 有证据 |
| “就这一次” | 没有例外 |
| “代码检查过了” | 代码检查 ≠ 编译器 |
| “代理说成功了” | 要独立验证 |
| “我太累了” | 疲惫 ≠ 借口 |
| “部分检查就够了” | 局部结果说明不了什么 |
| “换个说法就不算违规” | 精神高于字面 |
测试:
✅ [运行测试命令] [看到:34/34 通过] “所有测试通过”
❌ “现在应该能过” / “看起来对了”
回归测试(TDD 红绿循环):
✅ 写 → 运行(通过)→ 撤销修复 → 运行(必须失败)→ 恢复 → 运行(通过)
❌ “我已经写了回归测试”(但没有验证红绿循环)
构建:
✅ [运行构建] [看到:退出码 0] “构建通过”
❌ “代码检查通过了”(代码检查不等于编译)
硬件验收:
✅ 刷写目标板 + 人工观察/测量 + 记录结果
❌ 只有 host 构建、单测、脚本输出或代理口头确认
需求:
✅ 重读计划 → 创建清单 → 逐项验证 → 汇报缺口或完成情况
❌ “测试通过了,阶段完成”
代理委派:
✅ 代理报告成功 → 检查 VCS diff → 验证改动 → 汇报真实状态
❌ 直接相信代理报告
来自 24 次失败记忆:
始终在以下之前执行:
这条规则适用于:
验证没有捷径,证据必须匹配结论。
先跑命令。先读输出。软件结果用命令证实,硬件结果用现场或人工证据证实,然后再下结论。
这条规则没有商量余地。