OpenClaw 技能装好了却不会调用怎么办：触发条件、权限和环境变量排查

Skills 装好了却不调用，这个问题我最近碰得比安装失败还多。因为它看起来像“功能坏了”，实际上往往只是触发条件、权限或者环境变量没有对上。

所以这篇不再讲怎么安装，我只讲怎么排。你可以把它当成一个现场排查清单来用。

先判断是没加载、没资格、没触发，还是被环境和权限挡住了。

一、第一步先看它有没有资格被调用

openclaw skills list
openclaw skills list --eligible
openclaw skills info deploy-helper

如果 list 能看到、但 list --eligible 看不到，这时就别再怀疑提示词了，先去查依赖。

表现	先查什么	我通常怎么修
技能完全不在 list 里	目录位置和文件名	先确认是不是放错了目录，`SKILL.md` 有没有真的建出来。
在 list 里，但不在 eligible 里	二进制和环境变量	优先看 `requires.bins`、`requires.env`，再看 PATH 和 shell 启动方式。
eligible 正常，但还是不触发	提示词是否具体	第一次调试时我会直接点名 Skill，先验证链路，再追求自然触发。
本机能跑，沙箱里不行	容器内依赖	宿主机有命令不代表隔离环境也有，需要把依赖一并装进容器。
偶发触发、偶发不触发	工作区范围	检查 Skill 是全局的还是项目级的，别在 A 项目里调 B 项目的技能。

二、环境变量是最容易漏的点

很多 Skill 看起来像是“不会调用”，实际是它要求的环境变量根本不存在。这个坑尤其容易出现在你换了终端、换了启动方式或者换了用户之后。

echo "$KUBECONFIG"
echo "$GITHUB_TOKEN"
which kubectl
which rg

我一般会把 openclaw skills info <name> 输出里的依赖抄出来，和当前 shell 里的变量、命令逐个核一下，别凭感觉猜。

顺序别反了：先确认资格，再查环境，再修提示词，最后再看权限策略。

三、提示词写得太泛，也会让技能像没装一样

反例：帮我看看这个项目。
正例：请用 deploy-helper 这个 skill 检查 test 命名空间里 payment 服务的 deployment、pod 和 events。

不是说每次都必须手动点名 Skill，而是排查阶段要故意把问题收窄。这样你能很快分清楚到底是触发规则的问题，还是技能本身根本不可用。

四、如果你怀疑是日志问题，我会这么看

[skills] skipped deploy-helper: missing env KUBECONFIG
[skills] skipped repo-grep: missing bin rg inside sandbox
[skills] deploy-helper loaded and eligible

上面这种日志格式是我现场经常会整理出来的关键点，不一定和你环境里一模一样，但排查思路是一样的：先找 skipped 原因，再找 eligible 结论。