メニュー
在声称工作完成、修复或通过前使用，在提交或创建 PR 前 - 要求运行验证命令并在做任何成功声称前确认输出
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | dev-verification |
| description | 在声称工作完成、修复或通过前使用，在提交或创建 PR 前 - 要求运行验证命令并在做任何成功声称前确认输出 |
未经验证声称工作完成是不诚实，不是效率。
核心原则： 证据先于声称，永远。
违反此规则的文字就是违反规则的精神。
没有新鲜验证证据就没有完成声称
如果你在本消息中还没有运行验证命令，你不能声称它通过。
在声称任何状态或表达满意前：
1. 识别：什么命令证明这个声称？
2. 运行：执行完整命令（新鲜、完整）
3. 阅读：完整输出，检查退出码，计数失败
4. 验证：输出是否确认声称？
- 如果不：用证据陈述实际状态
- 如果是：用证据陈述声称
5. 只有这样：做出声称
跳过任何步骤 = 撒谎，不是验证
| 声称 | 需要 | 不足够 |
|---|---|---|
| 测试通过 | 测试命令输出：0 失败 | 之前运行，"应该通过" |
| Linter 干净 | Linter 输出：0 错误 | 部分检查，外推 |
| 构建成功 | 构建命令：exit 0 | Linter 通过，日志看起来好 |
| Bug 修复 | 测试原始症状：通过 | 代码更改，假设修复 |
| 回归测试有效 | 红-绿循环验证 | 测试通过一次 |
| Agent 完成 | VCS diff 显示更改 | Agent 报告"成功" |
| 需求满足 | 逐行检查清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "现在应该有效" | 运行验证 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "Agent 说成功" | 独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查就够了" | 部分证明不了什么 |
| "不同措辞所以规则不适用" | 精神高于文字 |
测试：
✅ [运行测试命令] [看：34/34 通过] "所有测试通过"
❌ "现在应该通过" / "看起来正确"
回归测试（TDD 红-绿）：
✅ 编写 → 运行（通过）→ 恢复修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我已经写了回归测试"（没有红绿验证）
构建：
✅ [运行构建] [看：exit 0] "构建通过"
❌ "Linter 通过"（linter 不检查编译）
需求：
✅ 重读计划 → 创建检查清单 → 验证每个 → 报告缺口或完成
❌ "测试通过，阶段完成"
Agent 委派：
✅ Agent 报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态
❌ 信任 agent 报告
失败记忆：
总是在以下情况前：
规则适用于：
验证没有捷径。
运行命令。阅读输出。然后声称结果。
这是不可协商的。
何时使用需要为编程项目、monorepo 或多级目录创建/更新 AGENTS.md、CLAUDE.md 软链接、项目级 agent 操作手册、子目录局部规则、验证命令和 Coding Agent 上下文边界时使用。
分析代码库结构并生成中文 token-lean 架构文档。
用于构建或维护个人 LLM 驱动的知识库。触发词：将资料导入 wiki、查询 wiki 知识、检查 wiki 质量、'添加到 wiki'、'我了解什么关于'，或任何提到 'LLM wiki' 的场景。
当有书面实施计划要在单独会话中执行并带审查检查点时使用
用户明确要求隔离工作区、并行分支验证或临时试验时使用 - 创建隔离的 git worktree
开始开发编程相关对话时使用 - 建立如何查找和使用 skills，在做出任何响应前要求先检查适用的 skill