在开始新功能或项目之前,通过对话明确目的、偏好和限制。根据需要用图示或原型核对理解,并按工作规模整理说明或设计文档。
- 明确新功能的目的
- 整理演讲或商业构想
- 比较界面或房间布局
在报告任务完成或修复成功前运行测试、构建等检查,核对完整输出,并在提交修改或创建拉取请求前,以当前实际结果为依据说明状态。
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
在报告任务完成或修复成功前,先进行能够支撑结论的验证。选择可验证该结论的命令并运行,检查完整输出、退出码和失败数量,再说明当前状态。测试、构建和代码规范检查分别处理,各自需要相应证据。对于需求是否满足,会逐项核对;对于其他智能体所做的修改,也会结合差异和验证结果进行检查。
适合提交修复后的代码、准备提交修改或创建拉取请求时使用。帮助确认哪些内容已经验证、还存在哪些问题,避免仅凭以前的测试结果或“应该能运行”的判断,就将工作视为完成。
需要能够验证目标工作的命令及运行环境。以前的运行结果或局部检查不能作为当前成功的证据。如果结果不足以支撑结论,会如实报告实际状态及相关证据。
本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。
AI 仅根据 SKILL.md 的内容,从 4 个方面进行了评估。星标数和热度不计入评估。
总分按每项 A=25 分、B=15 分、C=5 分相加。 由 AI(OpenAI Codex)于 2026年10月19日 评估。仅供参考,安装前请同时查看原文。
安装前可以查看交给 AI 代理的指令内容。
Core principle: Evidence before claims, always.
Violating the letter of this rule is violating the spirit of this rule.
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this message, you cannot claim it passes.
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
- If NO: State actual status with evidence
- If YES: State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying
| Claim | Requires | Not Sufficient |
|---|---|---|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | Test passes once |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler |
| "Agent said success" | Verify independently |
| "I'm tired" | Exhaustion ≠ excuse |
| "Partial check is enough" | Partial proves nothing |
| "Different words so rule doesn't apply" | Spirit over letter |
Tests:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
Regression tests (TDD Red-Green):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
Build:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
Agent delegation:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
ALWAYS before:
Rule applies to:
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
在开始新功能或项目之前,通过对话明确目的、偏好和限制。根据需要用图示或原型核对理解,并按工作规模整理说明或设计文档。
读取 superpowers 会话记录,调查重复工作、偏离计划、耗时及令牌消耗。以文件路径和行号为依据整理经过,生成有证据支持的报告。
将相互独立的缺陷或测试失败分配给不同代理,并行调查和修复。明确各自范围与报告要求,再检查修改冲突、运行完整测试并整合结果。
在同一会话中逐项执行已有的实施计划,确认测试先失败后通过,记录进度与判断,并在全部任务结束后审查整个分支的更改。
在实现完成后检查全部测试,让用户选择本地合并、创建拉取请求或保留现状,并执行所选操作,再根据选择和工作环境整理分支与工作区。
将代码审查意见与实际代码、支持的运行环境及现有行为进行核对,确认建议是否合理,梳理疑问并依据技术证据回复,再逐项修改和测试。