在 Skills 独立总图 中，本节对应 C 发起调用。追踪用户和模型两种入口，随后交给同一正文准备阶段。
本节的手动专用配置变体、文件位置与实验步骤见 S07.10 完整示例附录。
我想弄清楚的问题
Skill 已经被发现，为什么有时自动调用，有时要我输入 /review-diff？需要分清三个阶段：被系统发现、可供某一方调用、真正进入调用流程。
两条调用路径
- 蓝色：已有且保留
- 橙色：修改／职责迁移（本图未用）
- 紫色：本节核心机制
- 红色虚线：真实移除（本图未用）
- 灰色实线框：存储／辅助节点（本图未用）
- 灰色虚线框：细节合并，功能保留（本图未用）
- 灰字：来源／补充说明
- 灰色虚线：关联，不是执行回环（本图未用）
- 实线箭头：流程／数据方向
用户可以明确点名：
/review-diff
也可以提出任务：
帮我检查这次未提交改动，重点找可能改变行为的缺陷。
第二条路径中，Claude 根据任务与 Skill 描述判断是否相关，再发起技能调用。描述帮助选择，但自然语言匹配会受措辞和当前上下文影响，不能保证所有相关请求都触发。
手动调用已经指定了 Skill，因此只能验证它能否运行；要判断自动选择是否可靠，必须另外使用自然语言任务测试。
描述要提供哪些信息
描述应该能回答“做什么、什么时候用”。例如：
description: 检查当前 Git 仓库的未提交改动。用户要求审查 diff、排查改动风险或检查这次修改时使用。
这比“帮助写出高质量代码”更容易判断任务是否匹配。我的写作原则是把真正的使用场景放在前面，避免把所有相关关键词都堆进去；否则一个审查 Skill 可能连普通概念解释也抢着接管。
两个开关分别控制什么
下面每行都是一种独立配置：
| 配置 | 用户能用 /name | 模型能主动调用 | 描述默认进入模型目录 |
|---|---|---|---|
| 默认 | 能 | 能 | 会 |
disable-model-invocation: true | 能 | 不能 | 不会 |
user-invocable: false | 不能 | 能 | 会 |
官网调用控制说明了这些差异。一个字段控制模型发起，另一个控制用户命令入口；它们不是互相替代的同义词。
若把本例改为只由我启动，可以加：
disable-model-invocation: true
这时期待它从“帮我检查改动”中自动触发，就与配置矛盾。
调用还要经过应用侧检查
模型认为相关并不等于应用一定允许启动。Skill 工具本身的权限规则、组织策略或技能可见性配置，都可能让请求被拒绝。失败发生在调用入口时，正文可能尚未被加载，不能据此判断正文写得不好。
因此排查顺序是：当前会话是否发现该 Skill → 当前调用者是否能调用 → 请求是否被允许 → 正文是否成功装载。
我的理解
目录描述让模型知道有哪些可选方法；自动匹配由模型判断，调用边界由应用配置处理。想要特定方法时，我可以直接点名；想检验它能否自己找对方法，就必须测试自动调用路径。