메뉴
在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言。 / Use before claiming work is complete, fixed, or tests pass, and before commit / PR — run verification commands and confirm output before stating success; back every claim with evidence.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill when the task is specifically about AI search, AI Overviews, LLM citations, answer-engine optimization, or improving visibility in AI-generated answers. Good fit for AEO, GEO, LLMO, AI citations, zero-click AI visibility, and optimization for ChatGPT, Perplexity, Claude, Gemini, or similar systems. Do NOT use as the default for broad SEO audits or for pure schema implementation.
在创造性产品或设计工作之前使用此技能：创建新功能、构建新组件、添加新能力，或有意改变既定产品行为。在实现前先探索用户意图、需求和设计。不要用于 bug 修复、测试失败、构建失败、回归修复、恢复已有行为，或预期行为已经明确的实现任务；这些情况优先使用 systematic-debugging、test-driven-development 和 verification-before-completion。
Unified Impeccable frontend design skill. Use when the goal is to design, build, redesign, or improve a frontend interface — web pages, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, empty states, responsive behavior, typography, spacing, layout, color, motion, UX copy, accessibility, or UI-perceived performance. Also use for Impeccable command-style requests aimed at frontend work, such as `impeccable craft`, `shape`, `init`, `document`, `extract`, `critique`, `audit`, `polish`, `bolder`, `quieter`, `distill`, `harden`, `onboard`, `animate`, `colorize`, `typeset`, `layout`, `delight`, `overdrive`, `clarify`, `adapt`, `optimize`, `live` (`teach` is only a deprecated alias for `init`). Do NOT use for backend or non-frontend code audits, docs, or reviews; live-site design-language extraction; static poster or cover art; HTML slide decks; PowerPoint / PDF / Word / spreadsheet deliverables; or specialized React/Next performance work.
遇到 bug、测试失败、构建失败、生产事故或异常行为时使用；在提出修复方案之前先找根因，不要凭直觉打补丁。 / Use for bugs, test failures, build failures, production incidents, or unexpected behavior — investigate the root cause before proposing a fix; do not patch symptoms.
在实现新功能、有意的行为变更，或非平凡 bug 修复时使用——先写一个会失败的测试，再写实现代码。例外：一次性原型、生成代码、配置文件、单行 trivial 修改、纯文案/排版/样式调整，以及没有可测行为的改动。 / Use when implementing new features, intentional behavior changes, or non-trivial bug fixes — write a failing test before implementation. Exceptions: throwaway prototypes, generated code, config files, trivial single-line patches, copy / typography / pure style edits, and changes with no testable behavior.
当确实需要与当前工作区隔离时使用，例如并行开发、临时 hotfix、PR 检查、多方案实验或执行大型实现计划。不要作为日常小修、普通 bug 修复、只读调查或单文件改动的默认流程。
| name | verification-before-completion |
| description | 在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言。 / Use before claiming work is complete, fixed, or tests pass, and before commit / PR — run verification commands and confirm output before stating success; back every claim with evidence. |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["quality","verification"]}} |
在没有验证的情况下宣称工作完成，这不是高效，而是不诚实。
核心原则： 始终用证据支撑结论。
对这条规则敷衍了事，就等于违背了它的精神。
没有新鲜的验证证据，不许宣称完成
如果你在这条消息中没有运行验证命令，就不能声称测试通过。
在宣称任何状态或表达满意之前：
1. 确定：什么命令能证明这个结论？
2. 运行：执行完整命令（重新运行，完整执行）
3. 阅读：完整输出，检查退出码，统计失败数
4. 验证：输出是否支持这个结论？
- 如果否：用证据说明实际状态
- 如果是：带证据陈述结论
5. 只有这时：才能做出结论
跳过任何一步 = 说谎，不是验证
| 结论 | 需要 | 不够格 |
|---|---|---|
| 测试通过 | 测试命令输出：0 failures | 之前的运行结果、"应该会通过" |
| Linter 无报错 | Linter 输出：0 errors | 部分检查、推断 |
| 构建成功 | 构建命令：exit 0 | linter 通过、日志看起来没问题 |
| Bug 已修复 | 测试原始症状：通过 | 代码改了，假设已修复 |
| 回归测试有效 | 红-绿循环已验证 | 测试只通过了一次 |
| 代理已完成 | VCS diff 显示变更 | 代理报告"成功" |
| 需求已满足 | 逐项核对清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "应该能行了" | 运行验证命令 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "代理说成功了" | 独立验证 |
| "我累了" | 疲劳 ≠ 借口 |
| "部分检查就够了" | 部分检查什么也证明不了 |
| "换个说法这条规则就不适用了" | 精神大于字面 |
测试：
✅ [运行测试命令] [看到：34/34 pass] "全部测试通过"
❌ "应该能通过了" / "看起来对了"
回归测试（TDD 红-绿）：
✅ 编写 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我写了回归测试"（没有经过红-绿验证）
构建：
✅ [运行构建] [看到：exit 0] "构建通过"
❌ "Linter 通过了"（linter 不检查编译）
需求：
✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成
❌ "测试通过了，阶段完成"
代理委派：
✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任代理报告
来自 24 次失败记录：
以下情况之前必须使用：
本规则适用于：
验证没有捷径。
运行命令。阅读输出。然后才能宣称结果。
这没有商量余地。