メニュー
完成后验证技能。在声称完成、修复成功或测试通过之前，必须运行验证命令并确认输出，绝不允许在证据之前做出成功声明。 触发方式：完成、修好、通过了、可以提交了、搞定 Verification before completion skill. Run verification commands before claiming success. Trigger: done, fixed, passed, ready to commit, complete
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
头脑风暴技能。任何创意工作（创建功能、构建组件、添加功能或修改行为）之前必须使用——在实施之前探索用户意图、需求和设计。 触发方式：头脑风暴、创意、设计方案、想做新功能 Must use before any creative work - explores user intent, requirements, and design before implementation. Trigger: brainstorm, creative work, new feature, design, make a plan
并行代理分发技能。处理2个或以上相互独立、无共享状态或顺序依赖的任务时使用。 触发方式：并行任务、独立任务、多个任务同时、同时处理 Dispatch parallel agents for 2+ independent tasks without shared state or sequential dependencies. Trigger: parallel tasks, independent tasks, multiple tasks, simultaneous work
Exa 源头搜索技能。用于官方文档、API参考、定价页、产品规格等源头信息检索，需要低噪音高质量结果或页面正文提取时使用。 触发方式：查文档、API文档、官方说明、源头信息 Exa neural web search for official docs, API references, pricing pages, and source-first research. Trigger: official docs, API reference, pricing, source-first, official documentation
执行计划技能。在独立 session 中执行书面实施计划，按检查点逐步完成任务。 触发方式：执行计划、按计划执行、运行任务、执行任务列表 Execute implementation plans skill. Execute written plans in an isolated session with checkpoints. Trigger: execute plan, follow the plan, run tasks, implementation
完成开发分支技能。开发完成、测试通过后，决定如何整合工作——Merge、PR 或清理。 触发方式：完成、开发完、合并、创建PR、收尾 Finish development branch skill. After implementation is complete and tests pass, decide how to integrate work. Trigger: finish, complete, merge, PR, development branch
Finnhub 美股数据技能。当工作区在 .env 中配置了 FINNHUB_API_KEY 时，使用 Finnhub 获取美股和加密货币市场数据。 触发方式：美股行情、NVDA财报、个股分析、美股新闻 Fetch US stock and crypto market data via Finnhub API. Trigger: US stock quote, NVDA, AAPL, TSLA, company profile, stock news
| name | verification-before-completion |
| description | 完成后验证技能。在声称完成、修复成功或测试通过之前，必须运行验证命令并确认输出，绝不允许在证据之前做出成功声明。 触发方式：完成、修好、通过了、可以提交了、搞定 Verification before completion skill. Run verification commands before claiming success. Trigger: done, fixed, passed, ready to commit, complete |
没有验证就声称完成是不诚实，不是效率。
核心原则：证据在声明之前，永远如此。
违反这条规则的字面规定，就是违反其精神。
未经新鲜验证证据，不得做出完成声明
（NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE）
如果还没有在这个消息中运行验证命令，不能声称它通过了。
在声称任何状态或表达满意之前：
1. 识别：什么命令证明这个声明？
2. 运行：执行完整命令（新鲜的，完整的）
3. 读取：完整输出，检查退出码，计数失败
4. 验证：输出是否确认声明？
- 如果否：用证据陈述实际状态
- 如果是：用证据陈述声明
5. 只有那时：做出声明
跳过任何步骤 = 撒谎，不是验证
| 声明 | 需要 | 不充分 |
|---|---|---|
| 测试通过 | 测试命令输出：0 failures | 之前运行，"应该通过" |
| Linter 干净 | Linter 输出：0 errors | 部分检查，推测 |
| 构建成功 | 构建命令：exit 0 | Linter 通过，日志看起来好 |
| Bug 修复 | 测试原始症状：通过 | 代码改了，假定修复 |
| 回归测试有效 | Red-green 循环验证 | 测试通过一次 |
| Agent 完成 | VCS diff 显示变更 | Agent 报告"成功" |
| 需求满足 | 逐行检查清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "现在应该 work 了" | 运行验证 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "Agent 说成功了" | 独立验证 |
| "我累了" | 疲劳 ≠ 借口 |
| "部分检查就够了" | 部分证明不了什么 |
| "换了词规则就不适用了" | 精神优先于字面 |
测试：
✅ [运行测试命令] [看到：34/34 通过] "所有测试通过"
❌ "应该现在通过了" / "看起来正确"
回归测试（TDD Red-Green）：
✅ 写 → 运行（通过）→ 回滚修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我写了回归测试"（没有 red-green 验证）
构建：
✅ [运行构建] [看到：exit 0] "构建通过"
❌ "Linter 通过了"（linter 不检查编译）
需求：
✅ 重读计划 → 创建检查清单 → 验证每个 → 报告缺口或完成
❌ "测试通过，阶段完成"
Agent 委托：
✅ Agent 报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任 Agent 报告
从 24 个失败记忆中：
永远在之前：
规则适用于：
验证没有捷径。
运行命令。读取输出。然后声称结果。
这是不可商榷的。