让技能触发得准：description 就是它的 API

4.1 自动加载是怎么发生的

模型并不会把你所有技能的正文都读一遍——那样上下文早就爆了。它看到的，只是每个技能的一行 description，组成一份”技能清单”。当你说”帮我写下这次的发布说明”，模型拿这句话去跟清单里每一条 description 做匹配，觉得哪条相关，才把那个技能的正文加载进来。

所以结论很反直觉但很重要：description 不是介绍词，它是这个技能对外的 API。模型能不能在对的时候想起你的技能，几乎全看这一行写得准不准。正文写得再好，description 没匹配上，技能根本不会被加载。

description 写得好的核心，是同时说清做什么和什么时候用，并且带上用户真实会说的那些词。

模糊写法	问题	精准写法
`处理发布相关的事`	没有触发词，“发布相关”太宽	`把改动整理成面向使用者的发布说明。当用户要写发布说明、release notes 或 changelog 时使用。`
`数据库工具`	模型不知道何时该用	`编写和审查数据库迁移脚本。当任务涉及 schema 变更、加索引、数据回填时使用。`
`代码质量`	太笼统，等于关掉自动触发	`审查 diff 里的正确性缺陷。当用户要 review 改动、检查 PR、合并前把关时使用。`

规律是：动词 + 对象 + “当……时使用”的触发条件，并且触发条件里放进用户会真实说出口的词（“release notes""changelog""review""合并前”）。写”处理数据”这种，基本等于把自动触发关掉了。

自动触发是好事，但不是所有技能都想要。一个会提交、部署、发消息的技能，你多半希望只有自己能按下按钮。

disable-model-invocation: true 就是那个开关。加上它之后：

一个 /commit 或 /deploy 技能就该这样：把触发权完全攥在你手里。这也顺带省了上下文——它的 description 平时根本不在清单里。

这里要给一句诚实的话：自动触发是概率行为，不是保证。同一句请求，措辞略有不同，命中与否可能就变了。所以别把”必须发生”的事托付给自动触发——那是钩子的活。

验证方法很朴素：写完 description，用三四种不同措辞去问同一件事，看技能是不是都被挂上了。比如对 release-notes，分别试”写下发布说明""整理一下 changelog""这次发版对用户有什么变化”。哪种没触发，就把那种措辞里的关键词补进 description。