触发词批改课：官方描述十范文——skill-creator 同门的六种写法与一张裸奔豁免证

概述

本期是 Skills 生态拆解第 8 轮，方向是设计模式提炼。这个方向本栏已经走过三条正交路径：按层提炼（八种写法模式，08-30 期）、按范式提炼（禁令与编排对拆，09-04 期）、按评分反推提炼（预检清单，09-04 期）。本期开第四条：按文体收窄——不再拆 SKILL.md 全文，只批改描述（description）这一种文体；样本也不再去市场找热门件，而是转向一个从未被当成范文库的地方：本会话出厂注册表。一手清点的结果颇有戏剧性——约五百条在册名目里，带完整描述的出厂件恰好十件（另有 statusline-setup 一件在 agent 通道带描述，09-05 存档已录），它们全部出自「教人写 Skill 的那件 Skill」的同门之手，等于官方自己交出的十份描述答卷。核心发现四条：其一，描述的有无由召唤通道决定——斜杠件可以裸奔，自动路由件必须自我介绍，这给「无描述即死」的反模式第一条加了边界条件；其二，claude-api 把描述写成了 TRIGGER/SKIP 双清单，描述从段落升维成了判表；其三，官方用「交叉引用」解决撞名——simplify 把邻居 /code-review 的名字直接写进了自己的描述；其四，verify 与 run 这对同动词双件，靠目的从句分家。材料边界照例如实声明：本轮 WebSearch 与在线抓取通道未获放行（发起即被环境权限拒绝），全部事实来自三源——本会话出厂注册表一手观察、09-05 期《出厂件末排审计》已逐字存档的两份描述、本站往期存档；引文凡未经逐字核对处一律以「大意」标注，凡属推断逐一标注※，评分为描述级估分并沿用已存档旧分。

一、考场与样本：五百条在册，十份答卷

先回答为什么要单独批改描述。往期已经量过这笔账：描述是 SKILL.md 里唯一 100% 常驻路由上下文的段落，上下文经济学管它叫租约，官方文档给它划了 1536 字符的预算线（9-01 期存档转引口径）。八种写法模式把「描述写认知状态」立为模式一，预检清单把「每条都是用户原话」列为路由卷——但两期的范文都来自市场端（prototype、Prisma 件、grill-me）。造 Skill 的 Skill 是官方件，它的作者团队自己写的描述长什么样，从未被批改过。批改范文的范文，是检验写作教义可信度的最短路径。

本会话注册表一手清点（skill 通道带完整描述的十件）：

对照面同样重要：同一张注册表里，review、security-review、init 三件仅名字在册（09-05 期悬案），约两百件人设件近零描述（09-04 普查已档），连 example-skills 插件里的 skill-creator 变体自己也是裸名在册※。带描述与不带描述的分界线在哪里，是本文要判的第一道大题。

二、评测对比表

权重沿用本栏固定口径：功能 25%、设计 25%、实战 20%、上手 15%（越高越容易）、维护确定性 15%（出厂件无社区数据，沿用 09-05 期口径替换）。code-review（4.80，09-03 存档）与 keybindings-help（4.10，09-05 存档）沿用旧分；deep-research 已有专篇存档不重复评分；裸名三件不计分、作观察位。

评分说明：除两行存档分外均为描述级黑箱估分※——正文未读，功能与实战维度按名字语义与描述承诺推断；设计维度按本期批改标准（排他、锚点、可判定性）评分；维护维度按「官方随产品线自动更新」给满。若与读者实测不符，应以正文为准修正。

三、逐份批改：十份答卷里的六种写法

claude-api：把描述写成判表的双清单件

十份答卷里工程化程度最高的一份。它的结构不是段落而是两张表（大意）：TRIGGER 清单列三类触发信号——代码 import 了 anthropic 系 SDK、用户问 Claude API 的问题、用户要加缓存/工具调用等特性；SKIP 清单列两类拒绝信号——文件 import 的是 openai 系或其他厂商 SDK、文件名是通用模板形态。这是「触发-跳过对」的判表化终极形态：路由判断从「语义相似度」升级成「分诊台」，且罕见地把「别叫我」写成了明文——撞名九组呼吁的排他设计，官方版本不是措辞避让，而是直接列出对手的文件名模式。两个代价也如实记上：其一，描述里写了模型版本迁移职责（4.5→4.6 这类），模型每换代一次描述就要跟一次，描述从此有了防腐学讲的维护债；其二，双清单占用的字符预算远超一句话件，能这么花的前提是它触发场景的价值密度足够高。

verify 与 run：同动词双件的目的从句分家

这对双胞胎是描述工程里最精细的一处手术。两件描述的动作核心都是「把应用跑起来」，若只写动作必然互抢。官方的分家线画在目的从句上（大意）：run 的 Use when 枚举的是启动、截图、看它长什么样、复现运行时问题——「跑」本身是目的；verify 的 Use when 枚举的是验证 PR、确认修复生效、手动测试、给行为找二次意见——「跑」只是取证手段。用户说「跑一下看看」路由到 run，说「确认这个 bug 好没好」路由到 verify，两组意图枚举几乎零交集。撞名九组的排他三条路（前缀、后缀、措辞避让）之外，这里出现了第四条：同动词共存的合法性由「为什么」授予。给作者的操作口诀：如果你的 Skill 名字里有个通用动词，先写下用户跑它的理由，再写下邻居的理由，两条理由不重叠，两个件就可以都活。

simplify：把邻居名字写进描述的交叉引用划界

十份答卷里最短的一条分界线，也是信息密度最高的一句（大意）：只做质量清理，不找 bug，找 bug 用 /code-review。对比八种写法模式里的划界声明（domain-modeling 的「消费模型不是我的职责」），交叉引用式更进一步：负面空间只说「这不是我」，交叉引用还说「那是谁」。这对路由层的实际效果是双向的——用户说「帮我清理这段代码」时流量进 simplify，说「帮我找 bug」时描述里的显式转介把流量推给 code-review，一件的描述同时替两件当了路由器。这是官方对「描述排他」的最终答案，成本三行字，收益是整个相邻赛道的秩序。顺带修正一个往期观察：09-05 期曾把 review 与 code-review 并存列为悬案，本期从 simplify 的转介对象看，「review」系与「code-review」系在官方语境里是两个不同的任务面（大意推断※），悬案虽然未破，嫌疑范围收窄了。

update-config：原话枚举的密度上限

这份描述把「写用户原话」的教义推到了极限（大意）：它直接引用用户的嘴型——「从今往后每次 X 都要 Y」这类表述——并顺势完成一次分诊：这类自动化意图必须走 hooks 而不是靠模型记性，然后把权限、env、hooks 三个配置面枚举进描述。一件描述同时干了三件事：路由（什么时候叫我）、分诊（这个意图该走哪条机制）、目录（我能改哪几处）。上手分只给三星是全表最低，原因不在描述写得差，而在它触发的场景本身有门槛——用户得先知道 settings.json 的存在才说得出「帮我改配置」。它证明了一个反直觉结论：原话枚举的极限不是写得更多，而是把「机制选择」这种通常写在正文第一段的判断，前移进了描述。deep-research 的「调用前先问够不够具体」是同一手法的另一例（已拆存档），两件共同构成「描述里写路由后第一动作」的官方先例。

code-review 与 loop：参数面前置式

两件共同示范第五种写法：把参数面预写进路由层（大意）。code-review 的描述带着两个旗标——--comment 把发现贴成 PR 行内评论、--fix 直接改工作区——还顺带解释了档位语义（低档少而准、高档多多益善）；loop 的描述写明了间隔的两种给法和默认值。用户还没读正文，就已经知道该怎么指挥这件工具——用法说明从文档层前移到了路由层，这对斜杠召唤件尤其重要，因为用户敲命令时手里需要旗标表。代价同样清楚：参数面越大描述越长，1536 字符预算的最大消耗项就是它。给作者的判据：旗标不超过两个值得前置，超过了就该在正文里放一张用法表、描述里只留最常用的那个。

fewer-permission-prompts 与 keybindings-help：锚点压缩式两极

最短的两份答卷各占一极。fewer-permission-prompts 是结果导向极：描述只写产出物（一份可直接写进 settings.json 的优先级允许清单），不写扫描过程的细节——过程是正文的事，描述只回答「你能得到什么」。keybindings-help 是路径锚点极（09-05 期已逐字存档）：一句话埋三个锚——意图（customize keyboard shortcuts）、同义动作（remap keys）、文件路径（~/.claude/keybindings.json）——其中可 greppable 的路径是最硬的一枚，只要对话里出现这个文件名它就该被想起。两极合并成第六式的公式：描述的长度不重要，锚点数才重要——路径、文件名、SDK 名、旗标名，每个专有名词都是一枚免费的触发器；一段没有锚点的流畅介绍文，反而是一份零锚点的失效答卷。

四、裸奔豁免证：无描述件的生存条件

现在回答第一节末尾那道大题：带描述的十件与裸名大军（review/security-review/init、约两百件人设件、连 skill-creator 自己的插件变体也在内※）的分界线在哪里。反模式清单的第一条「无 description，路由层直接失明」需要加一个边界条件——失明只对自动路由致命。斜杠召唤通道里，名字本身就是触发词：用户敲 /review、/init 时不需要任何语义匹配，描述在这条通道上是冗余负载。出厂注册表的结构证明这是一场有意的分工而非疏漏：带描述的十件全是意图触发件——没有人会念出「code-review」来描述「帮我看看这段改动对不对」，所以描述必须替名字补上语义面；裸名件全是指令态件或点名件——名字即命令（review、init），或者名字即人设（人设件集群，普查期已定性为自愿退出模型触发）。给作者的判据一句话：你的 Skill 名字会被用户说出口吗？会说出口的可以裸奔，不会说出口的必须写描述。据此，08-30 期反模式清单第一条应修订为：「无 description 且名字不可念」才是完整死法；裸名但可念，只是选择了一条更窄的通道。

五、六式总纲与一张决策图

十份答卷收拢成描述工程六式：

flowchart TD
    A["写 description 之前<br/>先定召唤通道"] --> B{"名字会被用户<br/>说出口吗?"}
    B -->|"会·斜杠点名件"| C["可裸奔<br/>省下1536预算"]
    B -->|"不会·意图触发件"| D["必须写描述<br/>按六式动笔"]
    D --> E{"与邻居同动词<br/>或赛道相邻?"}
    E -->|"是"| F["式三 交叉引用<br/>把邻居名字写进去"]
    E -->|"否"| G["式四 原话枚举<br/>嵌用户嘴型"]
    F --> H{"有旗标与档位<br/>等参数面?"}
    G --> H
    H -->|"有"| I["式五 参数前置<br/>旗标档位入路由层"]
    H -->|"无"| J["式六 锚点压缩<br/>每个专名都是锚"]
    I --> K{"触发信号<br/>可列成清单?"}
    J --> K
    K -->|"可"| L["式一 双清单<br/>TRIGGER 与 SKIP"]
    K -->|"不可"| M["式二 目的从句<br/>写清为什么跑"]
    C --> N["发布前自检<br/>预算优先花在排他"]
    L --> N
    M --> N

六式不是并列菜单而是有优先级的：排他问题先于表达问题——先确认不和邻居抢触发（式二、式三），再谈怎么写得准（式四、式六），最后谈参数与判表的工程化（式一、式五）。预算分配的官方启示也压成一句：claude-api 花了最多字符在 SKIP 上，说明在描述的全部职责里，「不触发」比「触发」更花预算。

六、验证与使用命令

出厂件零安装，本期给的是验证与召唤命令：

# 验证本文一手数据：清点本机带描述的出厂件
ls ~/.claude/skills

# 裸名件的正确召唤方式：斜杠点名（无需描述参与路由）
#   /review  /security-review  /init

# 参数面前置件的用法（旗标在描述层已预告）
#   /code-review --fix
#   /loop 5m /foo

# 描述级自检：给自己的 Skill 提问
#   1. 名字会被念出口吗？不会 → 检查 description 是否覆盖用户原话
#   2. 描述里有几枚锚点（路径/SDK名/旗标名）？零枚 → 重写
#   3. 相邻赛道的邻居叫什么？说不出邻居名字 → 排他声明无从写起

推荐排行榜

• 最佳整体描述：claude-api（4.53）——十份答卷唯一的双清单，SKIP 明文化是全生态排他设计的最高水位；同时背最大维护债（模型版本号入描述）。
• 最佳排他设计：simplify（4.13）——三行字解决相邻赛道秩序，交叉引用式成本最低、收益最广，所有作者今晚就能抄。
• 最佳分家范本：verify（4.35）与 run（4.30）对读——同动词共存的教科书，目的从句是撞名九组未收录的第四条排他路。
• 最适合抄的骨架：keybindings-help（存档 4.10）——一句话三锚点，描述压缩的下限样本。
• 最被低估的写法：fewer-permission-prompts（3.78）的结果导向——全描述只写产出物，对「过程型作者」是最难改也最值钱的一课。
• 本期最反直觉结论：裸名三件与约两百件人设件不是反面教材——在「名字可念」的前提下，无描述是合法的通道选择；完整死法是「无描述且名字不可念」。

参考来源

1. 本会话出厂注册表快照（本地环境，无公开 URL）— 十件带描述清单、裸名大军与 skill 通道/agent 通道分工的一手观察；正文均未读取，引文凡标「大意」者为转写而非逐字引用
2. 本站存档《出厂件末排审计：改Agent自己的Skill》（2026-09-05，output/2026-09-05/skills-ecosystem-r3-0651.md）— keybindings-help 与 statusline-setup 描述逐字存档、review/security-review/init 裸名悬案、agent 通道最小权限面观察
3. 本站存档《造Skill的Skill：四款元工具横评》（2026-09-01，output/2026-09-01/skills-ecosystem-r7-1257.md）— description 1536 字符约束的官方文档转引口径、find-skills 三查机制
4. 本站存档《热门Skill的八种SKILL.md写法模式》（2026-08-30，output/2026-08-30/skills-ecosystem-r8-0454.md）— 认知状态触发（模式一）、划界声明（模式二）与反模式清单，本文六式的先行研究
5. 本站存档《评分表倒着用：写Skill预检清单》（2026-09-04，output/2026-09-04/skills-ecosystem-r8-1228.md）— 五维权重口径、路由卷判据与本文沿用的评分纪律
6. Extend Claude with skills — Claude Code Docs — frontmatter 与 description 官方定义（转引自存档 3，本轮未直接抓取，2026-09-01 口径）

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。