这不是三个同义词。Tool 是 Agent 能调用的动作，Skill 是教 Agent 怎样使用已有能力的说明，Plugin 是把新运行能力装进 OpenClaw 的代码包。 Tool policy 则负责收窄 Agent 能看到和调用的动作。
旧教程常把 ClawHub 当成“Skill 市场”，也容易把任何重复任务都升级为 Plugin。当前官方文档已经明确：ClawHub 同时托管 Skills 和 Plugins；Plugin 还能携带 Skill，但 Skill 本身不会授予工具权限。
先用四个问题完成路由
按顺序问，不要从“市场里有什么”开始：
- OpenClaw 当前是否已经有完成动作的 Tool？
- 需求是一次调用，还是一套需要反复复用的步骤与验收规则？
- 是否必须加入新代码、渠道、模型提供商、hook 或协议？
- 是否涉及凭据、后台服务、启动停止和卸载残留？
| 情况 | 首选 | 原因 |
|---|---|---|
| 已有能力，只做一次动作 | Tool | 直接调用即可 |
| 已有能力，需要稳定流程 | Skill | 保存步骤、边界与验收 |
| 已有能力，但权限过宽 | Tool policy | 收窄现有工具，不增加扩展 |
| 缺少运行能力或集成 | Plugin | 加入代码、合同和生命周期 |
如果一个“Skill”要求你先运行陌生安装脚本、启动后台服务或放入新二进制，它实际上已经跨入代码供应链审查范围，不能只按提示词文件看待。
1. 用六个固定案例校准判断
打开决策表，先隐藏 expected_surface 与 reason 两列。逐行写下你的选择和理由，再显示答案：
- E01：已有 browser，只缺每周登录导出流程 → Skill。
- E02：已有 exec，只想限制命令 → Tool policy。
- E03：新增 CRM API、凭据和写入 → Plugin。
- E04：已有天气工具，只查一次 → Tool。
- E05：已有文件与 shell，需要事故分级流程 → Skill。
- E06：新增内部消息渠道和原路回复 → Plugin。
六题全对后再审查真实候选。若 E02 或 E04 也选 Plugin，说明你在用安装代码代替简单配置；若 E03 或 E06 选 Skill，说明你把“怎样做”误当成“系统已经能做”。
2. 先列出现有能力
在当前工作区保存只读基线：
openclaw skills list --json > before-skills.json
openclaw plugins list --json > before-plugins.json再检查 Agent 当前工具和策略。内置或已安装的 Tool 能完成动作时，不要为了包装感重复安装 Plugin。需要复用时，Skill 应写清触发条件、输入、调用哪些 Tools、停止条件和验收，而不是重新实现工具。
3. 在 ClawHub 搜索时先识别 family
当前原生 CLI 分开搜索：
openclaw skills search "calendar"
openclaw plugins search "calendar" --jsonSkill 使用 openclaw skills install @owner/slug；ClawHub Plugin 使用明确前缀 openclaw plugins install clawhub:<package>。不要把搜索命中当成信任结论。记录 publisher、精确版本、family、扫描摘要和来源，再决定是否继续。
生产环境优先固定版本。无版本选择器通常会跟随更新线，适合探索却不利于复现实验；具体锁定行为以候选页面和当前 CLI 输出为准。
4. Skill 审查什么
至少打开 SKILL.md 和支持文件，回答：
- 什么时候触发，是否会在普通对话中误触发？
- 要求哪些 Tool、命令、路径和网络访问？
- 会读取或发送什么数据？
- 遇到缺字段、权限不足和外部失败时是否停止？
- 同名 Skill 是否被更高优先级目录覆盖？
安装后使用完整清单确认它出现在正确 workspace 和 Agent 下。一次正常任务、一次不应触发的普通问题、一次越界输入和一次缺工具测试，比“安装成功”更能说明 Skill 可用。
5. Plugin 审查什么
Plugin 是可执行代码。除发布者和文件外，还要检查 manifest 声明的 capabilities、pluginApi、最低 Gateway 版本、依赖、凭据保存、网络目的地、后台进程与卸载策略。
第三方来源要求 capability consent 时，逐项看清再继续。--force 用于明确接受某些来源流程，不应成为跳过审查的默认参数；官方 CLI 仍会执行安装策略与安全检查。
如果你只做审查，到此停止。只有你已经信任候选且确实需要它时，才按照候选官方页面给出的精确来源和版本安装。
6. 分开验证本地发现与运行健康
安装后的 Plugin 先查本地：
openclaw plugins inspect <id> --json
openclaw plugins doctor --jsonplugins doctor 会检查 discovery、模块加载、兼容性和残留配置，但不会证明运行中的 Gateway 健康。启动或重载后还要检查：
openclaw health随后跑四个金丝雀：正常调用、缺凭据、越界动作和用户取消。记录实际 Tool 名、授权提示、网络目的地、输出和日志。只看到 Plugin 出现在列表中，不能算集成完成。
7. 退出机制也是选型条件
试点前就写清禁用、卸载、凭据撤销、后台服务停止和配置残留如何处理。可以先使用 --dry-run 查看卸载计划（以当前 plugins uninstall --help 为准），再操作测试环境。
最终结论只允许三种：
- 直接使用现有 Tool / policy：没有必要增加包。
- 编写或安装 Skill：工具已足够，复用收益大于维护成本。
- 安装 Plugin：新运行能力不可替代，来源、兼容性、权限和退出路径均已验收。
“ClawHub 搜到了”不是第四种结论。ClawHub 负责分发与来源记录，真正的选择仍由能力缺口、代码边界和风险证据决定。