grounding-skill-evalslisted

# grounding-skill-evals —— 怎么度量一个 cc-master skill > **这是项目自用的 dev skill，不随插件分发。** 它住在 `.claude/skills/`（给 cc-master 自己的贡献者用），不在 `skills/`（那是 ship 给插件用户的）。终端用户装 cc-master 永远看不到它——它只为度量*本仓*的 skill 而存在。 ## Overview 这个 skill 回答一个问题：**「这个 skill 到底好不好，怎么用数据说话？」** 它不写 skill 的 body（那是 `cc-master-skillsmith`），也不判断一个 skill 该不该存在（那是 `curating-skill-portfolios`）。它只管**度量**——给一个已经写出 body 的 skill 声明一份可消费的成功契约（J），接上本仓已有的三个 eval 脚本，并用三个借来的思想防止「自己骗自己说改好了」。 **核心原则：度量先于迭代。** 没有声明 J（成功 = 什么），评测就会逐 case 漂移、优化就会 reward-hack 碰巧在视野里的那个指标。没有 baseline、没有 holdout、没有改前预测，「我感觉改好了」就是在自欺。 > **本 skill 只借三个思想，不搬引擎。** 成熟的 skill 评测 / 优化方法论有一整套重型机器（重型 J 不变量集、多字段机器可读裁决 schema、带自动搜索 + 多候选 filter 的优化引擎、Pareto 前沿追踪、统计显著性 / 方差分析预检）。**本仓体量用不上**，只借 baseline-must-fail / holdout split / predict-then-validate 三个判别力思想，落在纯 prose checklist + 现有脚本上。任何「补个搜索引擎 / 加个多字段裁决 schema」的冲动都是照搬过度工程（红线——过度工程的边界见本 skill 的 When NOT to use / OUT of scope 与设计宪法的「不做」段）。 ## When to use - 刚给一个 skill 写完或改完 body，想要一份独立的成功度量再迭代。 - 要给本仓某个 skill 写 / 修轻量 J（分发 skill 用 `.design/OBJECTIVE.md`，dev-only skill 用 `OBJECTIVE.md`）。 - 改一个 skill 的 `description` 前后，想知道触发准确率（precision/recall/accuracy）有没有真的提升——跑 Track A。 - 改一个 skill 的纪律段 / 行为，想知道 with-skill vs without-skill 的行为差有没有真的拉开——跑 Track B。 - 怀疑 description 优化「过拟合到我脑子里那几个 query」——要 holdout split 验证。 - 改动前想立个可证��的预测、改完比对——predict-then-validate 防自欺。 ## When NOT to use（明确反例 + 移交） - **要写 / 改一个 skill 的 body**（craft 诊断、命名锚、流程骨架、纪律段怎么写）→ **`cc-master-skillsmith`**。本 skill 度量 body，不生产 body。 - **要决定一个 skill