当技能或代理需要对自己刚产出的实现做独立复核、并给出…

对刚完成的实现（文件、命令输出、配置）做批判性复核，确认产出是否真的符合既定目标，并返回可直接执行的 PASS/WARN/FAIL 判定。

适用场景

解决思路

1. 先确定运行模式：子代理模式下解析传入的 `check:` 块，把 `goal`、`artifacts`、`checks` 各字段当作自己的任务授权；用户模式下由用户直接调用 `/impl-validator`，通常附带对刚做之事的描述，从上下文推断 goal 与 artifacts。
2. 用户模式下一旦目标含糊，只问一个澄清问题；关键检查不要凭猜测继续。
3. Step 1 理解目标：用一句话复述目标；如果复述不出来，说明目标定义不清，标为 WARN。
4. Step 2 对每个 artifact（文件、输出、配置）逐项检查。先做存在性检查：确认文件/输出真的存在，并实际读一遍。
5. 做完整性检查：确认它包含目标所隐含的全部必需章节/字段。
6. 做正确性检查：内容是否与所述目标逻辑一致，重点找——残留的占位文本（`<TODO>`、`{{variable}}`、`INSERT HERE`）；复制粘贴错误（错误的工具名、错误的路径、过期日期）；逻辑矛盾（例如某个 diff 声称页面 X「只存在于 codex」，却又在 claude 下列出它）；缺失必需字段（例如 SKILL.md 缺少 `name:` 或 `description:` frontmatter）；off-by-one 或空集边界情况（例如在已知 vault 非空时 page count = 0）。
7. 做约定检查：是否符合项目既有模式——技能文件要有含 `name` 和 `description` 的 YAML frontmatter、指令用祈使句、步骤编号、无占位文本；wiki 页面要有全部必需 frontmatter 字段（`title`、`category`、`tags`、`sources`、`created`、`updated`）；shell 脚本要有 shebang 行、可 `chmod +x`、使用 `set -e`；plist 文件要 XML 合法、`Label` 与文件名一致、`ProgramArguments` 引用真实存在的路径。
8. Step 3 执行给定的检查：对 `checks:` 列表里的每一条都显式评估，不得跳过，逐条给出 PASS（已验证为真）/ WARN（大概率没问题但值得记一笔）/ FAIL（确定错误或缺失）。
9. Step 4 产出结论报告，格式为：`## impl-validator Report`，内含 **Goal:**（复述的目标）、### Checks 表格（列为 Check / Result / Note，每条一行解释）、### Overall: PASS / WARN / FAIL、**Issues to fix (FAIL):**（具体问题，尽量带文件路径和行号）、**Worth noting (WARN):**（非阻塞性观察）。
10. 按规则汇总整体结论：出现任一 FAIL → 整体 FAIL；无 FAIL 但有 WARN → 整体 WARN；全部 PASS → 整体 PASS。
11. Step 5 返回给调用方：子代理模式下把完整报告作为响应返回，由调用技能决定是否修复后再呈现给用户；用户模式下直接展示报告，若整体 FAIL 则主动提出帮忙修复。
12. 明确不检查的内容：风格偏好（牛津逗号、变量命名），除非它违反了约定；性能或效率（除非目标里提到）；目标本身是否是个好主意——只拿实现对照目标，不拿目标对照自己的意见；假设性的未来问题——只标记当前 artifact 中的实际问题。
13. 按严重度分级判断：FAIL = 必需 frontmatter 字段缺失、文件不存在、检查被确认为假；WARN = 硬编码路径可能在其他机器上失效、页数异常偏低；PASS = 检查被验证为真。

适用边界 · 注意事项

• 不要用它评判目标本身是否合理或是否为好主意——它只核对实现与目标是否一致。
• 不要检查代码风格偏好（冒号、变量命名）、性能效率，或假设性的未来问题，除非这些违反了约定或目标中明确提出。
• 目标含糊时不要靠猜测去做关键检查，应先提一个澄清问题。