写全了不等于会触发。Skill 敢合入，先过触发描述评测。
事情是这样的。
发版前夜，同事把「用例评审 Skill」合进仓库。目录齐了，「SKILL.md」 也写长了。第二天有人让 Agent 写周报，它却把评审 Skill 拉起来；真要评审用例时，又偶尔不触发，全靠口头提醒「请用那个 Skill」。
大家以为卡在模型不够聪明。坦率讲，卡点在：装进仓库的是文件；敢信触发的，是 description 过没过评测。
写全了不等于会触发。误触发与漏触发，比「字不够多」更贵。
本篇切口是公开仓库 anthropics/skills 里的 skill-creator：官方已把「写 evals、跑对照、调 description」做成可跟做流程（见官方说明）。它和近作切开——11-07/11-11 讲的是生命周期与变更四道门；本篇只钉一件事：触发描述能不能考试。
反常识：先测门面，再堆正文
很多人改 Skill，习惯往 body 和 「references/」 里塞规则。真正决定「这一轮要不要读完整 SKILL.md」的，往往是 frontmatter 里那两行 name + description。
官方 progressive disclosure 很直白：元数据常驻；正文按需加载；参考资料再按需。于是 description 太宽，会误触——不相干任务也拖进长上下文；太窄，会漏触——该用的场景永远不开火。
金句一：Skill 的第一道门禁不在脚本，在触发描述。
只测「装上后人工喊一声能跑通」，测的是演示，不是触发。演示绿、触发红，合入后会在别人的会话里悄悄爆炸。
两类 Skill 也要把账分开看：能力抬升类，靠技巧补模型短板；流程偏好类，把团队口径写死。前者可能随模型变强而该退役；后者更怕「触发漂了、流程还以为在跑」。不论哪类，触发评测都是合入前的公共闸，不是文案润色可选项。
命名脚手架：trigger → eval → refine
把本号用法收成三角，方便评审对齐：
1. trigger：为这个 Skill 准备三类提示——正例（该触发）、改写（同义换说法）、负例（近邻但不该触发）。
2. eval：跑触发结果；同时保留一条「有 Skill / 无 Skill」功能对照，防止只修好触发、弄坏输出。
3. refine：只改 description（必要时极小改 name），复跑同一套提示，直到误触与漏触双降。
金句二：合入前能指认最近一次误触或漏触，才叫养过触发；指不出，只是堆过文件。
负例不要写成「完全无关的废话」。最有杀伤力的是近邻句：评审 Skill 旁边放「帮我整理测试周报」「把失败用例归个类」——措辞像，职责却不是。改写正例也别偷懒，同义换说法不过关，说明 description 只记住了你个人的口头禅。
最小可抄闭环（约 90 分钟）
按公开仓库跟做，不要发明私有协议：
1. 装入口：打开 anthropics/skills，按 README 使用 skill-creator（Claude.ai / Cowork / Claude Code 插件均可）。
2. 选靶：挑本仓 1 个真实 Skill（别用玩具空文件）。抄下当前 「description」。
3. 写触发集：至少 3 正例 + 3 改写 + 3 负例。负例要故意近邻——例如「写周报」对「用例评审 Skill」。
4. 调门面再跑：让 skill-creator 分析 description 的误触/漏触倾向，改一版后复跑；需要时再加一条「有/无 Skill」输出对照。
命令与插件安装以仓库 README 为准；正文不摊长 URL。你要留下的资产不是聊天截图，而是：触发集文件 + 改前改后 description + 一次复跑记录。
官方还强调并行隔离跑 eval、以及有/无 Skill 的盲评对照：上下文串味会让「这一轮碰巧绿」看起来很美。测开落仓时，把触发集和复跑记录放进同一目录，比把结论写进群公告更可审计。
本号验收 3 条
缺任一条，不得在周会宣称「这个 Skill 已可合入」：
1. 触发集在仓：正例 / 改写 / 负例三类都有，且负例是近邻场景，不是瞎写无关句。
2. 能指认故障：能说出最近一次误触或漏触是哪条提示触发的。
3. 改门面后复跑：description 有 diff；同一套触发集至少复跑一轮，误触或漏触有下降信号。
如果你们已经有变更四道门，把「触发集复跑」嵌进回归环即可，不必另起山头。没有门禁的团队，至少先把这三条写成合入检查清单——否则 description 会在口头里越改越飘。
何时不该用这套
• 只有一个 Skill、且全员口头约定永远 「@」 调用：触发评测收益低，先把变更门禁做实。
• 你要验的是业务终态，不是 Agent 是否加载文件：那是终态门禁 / 浏览器冒烟题，别用 description 评测顶替。
• 把评测写成虚荣通过率：只报「10 条全绿」、不公开负例集——和假绿同构，本号不认。
金句三：模型升级会改触发；description 没有回归集，等于给未来的误触预留工位。
能力抬升类 Skill，还可能出现「无 Skill 也能过功能 eval」——那是退役信号，不是丢脸。触发评测帮你分清：该收紧描述、该改职责，还是该删。Skill 变多之后，description 精度会变成稀缺资源：太宽是噪音，太窄是死库存。
可执行结论：今天就能做的可复用步骤
1. 给本仓最常用的 1 个 Skill 建 「evals/triggers.md」：3+3+3。
2. 把 description 从「什么都能干」改成「何时必须用 / 何时禁止用」各一句。
3. 评审合入时多问一句：最近一次误触或漏触是哪条？复跑记录在哪？
评论区打两样就行：你现在最痛的是 误触发 还是 漏触发？以及负例里那条「近邻场景」你准备写成什么。我按高频场景补一版触发集模板。
