在 Skills 独立总图 中，本节对应 A–F 的一次完整调用。先串起 review-diff 的内容与行动，再验证触发和结果；最后才接回完整系统。
本节的完整评估案例、文件位置与实验步骤见 S07.10 完整示例附录。
我想弄清楚的问题
看见“加载了 review-diff”，能不能证明 Skill 写得好？只能证明某次调用发生。它是否在合适的任务上触发、是否改善报告、是否遵守范围，都需要单独观察。
这里介绍可实施的验证方法；这些案例是我设计的示例，不是已运行并取得成绩的评测。
先完整走一遍 review-diff
先沿默认 inline 路径，不加入动态命令或 fork。假设仓库中出现了下文的空列表回归，参考资料另放在 references/input-boundaries.md：
| 步骤 | 对应总图 | 这时发生什么 |
|---|---|---|
| 保存最小 Skill | A | SKILL.md 写明审查步骤和需要时读取的参考资料 |
| 应用发现它 | B | 当前允许模型看见的目录中出现名称与描述，完整正文尚未默认交给模型 |
用户输入 /review-diff | C | 显式指定目标，应用处理这次调用；不用再检验模型能否自动选对 |
| 正文进入当前会话 | D / E | 模型得到工作步骤，准备请求工具取得实际改动 |
| 模型检查改动 | E | 请求读取状态、diff 与相关代码；工具结果给出证据 |
| 发现空输入问题 | F | 需要时读取输入边界参考资料，把方法与代码对照 |
| 输出审查报告 | E | 指出 [] 的触发条件、错误表达式与检查范围，再判断结果是否合格 |
这条链中，Skill 文件提供方法，应用负责调用和内容交付，模型与工具完成取证。正文加载成功只是走到了中间一步，报告是否可靠还要看后面的证据。
读完本节，再到 S07.9 将这些阶段接回完整 Agent Loop。
先把“触发”与“结果”拆开
| 要验证什么 | 测试方式 | 主要观察 |
|---|---|---|
| 自动触发 | 用自然语言提出任务 | 应触发与不应触发的场景 |
| 正文执行效果 | 显式用 /review-diff | 输出是否满足证据和范围要求 |
| 整体增益 | 相同任务，有/无 Skill 比较 | 质量、耗时和上下文开销 |
官网评估方法强调分别观察调用与结果，并使用干净会话做基线比较。
不要把创作 Skill 时已有的背景带入所有验证会话：模型可能凭之前讨论补全缺失步骤，让不完整的正文看起来也能工作。
给自动触发准备正例和反例
针对我们的描述，可以先准备这些请求：
| 用户请求 | 我的预期 |
|---|---|
| “检查这次未提交改动里的潜在缺陷” | 应调用 |
| “帮我审查 diff，看看会不会破坏空输入处理” | 应调用 |
| “解释什么是渐进式披露” | 不需要调用 |
| “给我讲讲 Git 分支是什么” | 不需要调用 |
若反例也经常加载，描述可能太泛；若正例不加载，先检查发现与可见性，再改描述。手动 /review-diff 成功不解决这个选择问题。
给结果准备可核对的缺陷
准备一个有明确约定的改动，例如：
// Contract: an empty input list returns an empty string.
export function normalizeFirst(items) {
return items[0].trim();
}
对 []，items[0] 是 undefined，调用 trim() 会出错。这是本例可以核对的缺陷。报告至少应指出触发输入和具体表达式，而不是只说“建议增强健壮性”。
我的结果标准可以写成：
{
"case": "empty-list-regression",
"expected": [
"指出空列表触发 undefined.trim",
"给出文件位置和行为影响",
"没有未经请求修改文件",
"说明实际检查过的范围"
]
}
这段 JSON 是本专题自己定义的评估记录示例，不是某个插件专用的 eval 格式。项目、输入和检查标准固定后，才有可比较的结果。
和没有 Skill 的运行比较
用相同改动、模型、权限和任务提示，在新会话中分别观察有 Skill 与关闭 Skill 的情况。若要观察自动调用路径，两组都使用同一个自然语言请求。
对个人或项目 Skill，当前 Claude Code 可用 skillOverrides 临时设为 off；插件提供的 Skill 则需要按插件评估方式处理。关闭方法应随来源选取。
比较的不只是“抓到这个 bug 没有”，还包括证据是否更完整、无关问题是否减少、有没有不必要工具操作。模型存在波动时，用几次独立运行判断趋势，不把单次结果当成保证。
按实际阶段定位失败
| 现象 | 优先检查 |
|---|---|
/skills 里找不到 | 路径、来源、frontmatter、会话发现范围 |
| 手动成功，自动不调用 | 描述、调用控制和相关性判断 |
| 调用后没有正文 | 参数或动态命令渲染错误 |
| 已加载，却给出泛泛报告 | 步骤、证据要求、任务输入是否完整 |
| 子 Agent 说不知道背景 | Skill 与委派内容是否自包含 |
| 后续轮次忘了方法 | 内容生命周期、压缩及指令表达 |
| 报告合格，却出现不允许的写操作 | 工具权限和执行 Hook，而非仅改描述 |
格式检查也有价值，例如标准工具 skills-ref validate 可以检查技能格式；但通过格式校验，不能证明审查任务表现合格。依据：标准格式验证。
我的理解
Skill 的好坏最终要落到任务证据上：合适的时候能被找到并调用，加载后能改善结果，执行仍符合约束。描述、正文和执行控制的问题，应在各自的阶段调整。