一键导入
verification-before-completion
在声称工作完成、修复或通过之前使用,在提交或创建 PR 之前需要运行验证命令并确认输出;始终先有证据再做断言
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
在声称工作完成、修复或通过之前使用,在提交或创建 PR 之前需要运行验证命令并确认输出;始终先有证据再做断言
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
桌面/网关运行时内置的计划创建技能,用于生成可落盘、可调度、可批次执行的结构化计划包。
桌面/网关运行时内置的计划执行技能,用于按批次执行结构化计划包中的单个任务文件。
Use when demonstrating or verifying VibeWindow local plugin packaging, including plugin skills, MCP servers, hook declarations, and interface metadata.
当需要在编码前创建或更新实施计划时使用,尤其适用于多步骤功能开发、重构、包含多个活动部件的缺陷修复,或需要拆分为可独立执行并跟踪进度的任务文件的请求。
当你有书面实现计划需要在单独会话中执行,并带有审查检查点时使用
通过 `rustcodegraph` 命令行界面使用 RustCodeGraph 理解、导航或脚本化操作已索引代码库。当用户要求使用 RustCodeGraph、需要高性能搜索检索代码、需要符号/源码/调用流上下文、调用方/被调用方/影响分析或受影响测试选择时使用。
| name | verification-before-completion |
| description | 在声称工作完成、修复或通过之前使用,在提交或创建 PR 之前需要运行验证命令并确认输出;始终先有证据再做断言 |
未经验证就声称工作完成是不诚实,而非高效。
核心原则: 始终先有证据,再做断言。
违反规则的字面意思就是违反规则的精神。
没有最新验证证据,不得声称完成
如果你在这个消息中没有运行验证命令,你就不能声称它通过。
在声称任何状态或表达满意之前:
1. 识别:什么命令能证明这个声称?
2. 运行:执行完整命令(全新、完整)
3. 阅读:完整输出,检查退出码,统计失败数
4. 验证:输出是否确认了声称?
- 如果否:陈述实际状态并提供证据
- 如果是:陈述声称并提供证据
5. 然后才:做出声称
跳过任何步骤 = 撒谎,而非验证
| 声称 | 需要 | 不充分 |
|---|---|---|
| 测试通过 | 测试命令输出:0 个失败 | 之前的运行,"应该通过" |
| 代码检查清洁 | 代码检查输出:0 个错误 | 部分检查,外推 |
| 构建成功 | 构建命令:退出码 0 | 代码检查通过,日志看起来不错 |
| 错误已修复 | 测试原始症状:通过 | 代码已更改,假设已修复 |
| 回归测试有效 | 红绿循环已验证 | 测试通过一次 |
| 代理完成 | VCS 差异显示更改 | 代理报告"成功" |
| 需求已满足 | 逐行检查清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "现在应该可以工作" | 运行验证 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "代码检查通过了" | 代码检查 ≠ 编译器 |
| "代理说成功" | 独立验证 |
| "我累了" | 疲劳 ≠ 借口 |
| "部分检查就够了" | 部分证明不了什么 |
| "措辞不同所以规则不适用" | 精神高于字面 |
测试:
✅ [运行测试命令] [看到:34/34 通过] "所有测试通过"
❌ "现在应该通过" / "看起来正确"
回归测试(TDD 红绿):
✅ 编写 → 运行(通过)→ 撤销修复 → 运行(必须失败)→ 恢复 → 运行(通过)
❌ "我已经编写了回归测试"(没有红绿验证)
构建:
✅ [运行构建] [看到:退出码 0] "构建通过"
❌ "代码检查通过"(代码检查不检查编译)
需求:
✅ 重新阅读计划 → 创建检查清单 → 验证每一项 → 报告差距或完成
❌ "测试通过,阶段完成"
代理委托:
✅ 代理报告成功 → 检查 VCS 差异 → 验证更改 → 报告实际状态
❌ 信任代理报告
来自 24 次失败的记忆:
始终在以下情况之前:
规则适用于:
验证没有捷径。
运行命令。阅读输出。然后声称结果。
这是不可协商的。