激活 Skill
Gemini CLI 激活 Agent Skill 的方式、技能发现、reload、enable/disable 和验证是否真正生效。
安装 Skill 不等于它已经在当前任务中正确生效。你需要确认发现、启用和 reload 状态。
看得到 Skill 不等于本次会话已经用了 Skill。真正的证据是触发了激活确认，并且输出遵守 SKILL.md 的流程。
activate_skill 是 Gemini agent 内部调用的工具，用户不能手动执行。它只有一个参数：要激活的 Skill name。当模型判断任务匹配某个已发现 Skill 时，会请求激活；你确认后，Gemini CLI 才会把 Skill 正文和资源目录加入会话。
常用命令
gemini skills list
gemini skills enable <name>
gemini skills disable <name>交互式会话里：
/skills reload官方还区分交互命令和终端命令：交互里可以 /skills list [all] [nodesc]、/skills link <path>、/skills enable、/skills disable、/skills reload；终端里可以 gemini skills list --all、gemini skills install <path>、gemini skills uninstall <name>。教程要写清当前命令是在会话里输入，还是在 shell 里执行。
激活前后发生什么
激活前，模型只知道 Skill 的名称和描述。激活后，模型会得到：
SKILL.md正文。- Skill 目录结构。
- 读取 Skill 目录内
scripts/、references/、assets/的权限。 - Skill 中声明的流程、约束和资源使用方式。
所以“看得到 Skill”只代表发现成功，不代表它已经影响当前回答。真正生效的证据是：本次任务触发了激活确认，并且回答遵守 Skill 的流程。
激活会有 consent 流程，用户会看到 skill 名称、用途和目录访问范围。确认后，Gemini CLI 才把正文和资源注入会话。第三方 Skill 的风险也在这里：一旦确认，模型就能读取该 Skill 目录里的脚本、参考资料和资源。
验证方式
skills list能看到。- 状态是 enabled。
- 当前任务确实触发了对应 skill。
- 输出符合 skill 的输入输出契约。
- Skill 内脚本或参考资料按预期被读取。
排错
| 现象 | 检查 |
|---|---|
| list 看不到 | 安装路径或 link 路径 |
| 看得到但不触发 | 触发描述是否太模糊 |
| 触发后输出乱 | skill 说明是否缺输入输出 |
| 和项目规则冲突 | 对齐 GEMINI.md 和 skill 边界 |
| 验证层级 | 通过标准 |
|---|---|
| 发现 | /skills list 能看到正确 scope |
| 启用 | 状态是 enabled，reload 后仍存在 |
| 触发 | 明确任务会弹出激活确认 |
| 生效 | 回答遵守 Skill 流程和输出格式 |
| 资源 | 需要时能读取 scripts / references / assets |
触发调试方法
先写一个非常明确的测试 prompt，例如“请使用 code-reviewer skill 审查当前 staged diff”。如果这样能触发，说明安装和 reload 没问题，后续再优化 description 让自然语言请求也能命中。如果明确点名仍不触发，先检查 scope、禁用状态和路径。
不要通过把大段触发词堆进 SKILL.md 正文来解决触发问题。模型激活前看不到正文，触发质量主要由 description 决定。
激活成功后还要看输出是否真的改变：有没有使用 Skill 的固定步骤、是否读取了需要的参考资料、是否按约定格式收尾。只看到“我会使用这个 Skill”这句话，不算验收通过。
如果只是想强制使用某个流程，最稳的方法不是堆触发词，而是直接点名任务和 Skill 名称，然后观察是否出现激活确认。没有确认就没有真正加载；有确认但输出不按流程走，问题在 SKILL.md 本身。
接下来去哪
Subagents
Skill 是给当前 agent 加能力；复杂委托继续看 subagents。
Agent Skills
回看 Skill 生命周期、发现层级和管理命令。
Skills 最佳实践
触发不稳定时，优先改 description 和边界。