把你的技能发布到 ClawHub：从本地目录到公开注册表

一、先说个场景

你写了一个很好用的 Skill：它能把周报 Markdown 自动整理成三段式，还能生成邮件草稿。同事看了也想要，于是你把整个目录打包发给他。第二天他又来问：”更新了吗？””和另一个同名 skill 冲突怎么办？””我怎么知道安不安全？”

私下传文件还会带来一个隐性问题：你改了一处逻辑，得手动通知每个人重新下载；有人改了你的副本又发回给你，版本就乱成一团。技能一旦被多人使用，分发和版本就成了真正的负担。

与其私下传文件，不如发布到 ClawHub——OpenClaw 的公开技能注册表。别人只需要一个命令就能安装、校验、更新，和你自己维护的本地副本一样省心。

二、为什么是这样

ClawHub 相当于 OpenClaw 的”应用商店”。它解决三个问题：

1. 分发：一个命令就能安装，不用传 zip。
2. 信任：每个 skill 都有可校验的信任信封和安全扫描。
3. 版本：openclaw skills update --all 只跟踪 ClawHub 安装的技能，升级路径清晰。

对个人作者来说，发布到 ClawHub 意味着你的 skill 可以被社区发现、复用、反馈。对企业来说，也可以创建 organization owner，让团队成员按角色发布。

理解信任信封很关键：它是 ClawHub 给每个已发布 skill 附上的一种可校验凭证，记录了发布者、版本、扫描状态等信息。用户侧用 openclaw skills verify @owner/slug 就能查到这份”身份证”。换句话说，ClawHub 不只是把文件给你，还顺手给了你一份”这东西是谁发的、有没有被扫过”的证明。这也是它和普通网盘分享最本质的区别。

三、跟着做：分步操作

1. 发布前自检

确保 SKILL.md 具备：

• name：合法 slug。
• description：160 字符内，说清楚触发场景。
• gating 字段：依赖什么二进制、环境变量、平台。
• homepage（可选但推荐）：项目主页。

除了这些，name 和 description 之外，SKILL.md 还支持一系列可选字段，发布前应顺手想清楚：这个 skill 要不要 user-invocable、要不要 disable-model-invocation、要不要 emoji 在列表里更好认、限定在哪些 os 上可用、是否 always 常驻。它们不影响发布本身，但会影响别人装好之后的使用体验。

如果 skill 依赖外部二进制，用 metadata.openclaw.requires 声明，例如 requires: { bins: ["python3"], env: ["SOME_TOKEN"] }。这样别人的环境缺依赖时，安装或加载阶段就会被告知，而不是运行时才炸。

2. 安装并登录 ClawHub CLI

npm i -g clawhub
clawhub login

3. 发布

clawhub skill publish ./path/to/hello-world

覆盖版本或 owner：

clawhub skill publish ./path/to/hello-world --version 1.0.1 --owner @your-org

发布前最后一道自检：在本机用 openclaw skills check 看技能是否能正常被识别，再用 openclaw skills info <name> 确认 frontmatter 解析无误。等发出去再发现 description 超长或 name 不合法，就得重新发一版，既浪费又容易让老用户困惑。

4. 同步

clawhub sync --all

sync --all 用于把本地与注册表对齐。要区分它和 update --all：前者偏向”同步/对齐状态”，后者偏向”拉取已装技能的新版本”。两者经常一起用，但目的不同，别混为一谈。

5. 安装你的 skill

openclaw skills install @your-org/hello-world

对方用 clawhub install 安装时，默认落到当前目录的 ./skills。装好后，它进入技能加载体系：workspace 的 /skills 优先级最高，其次是 ~/.openclaw/skills，再是 bundled，最后是 extraDirs。所以同一个名字如果本地已有副本，安装版可能覆盖或被覆盖，发布前最好跟团队约定好统一的 owner 前缀，减少重名。装好之后，用户侧可用 openclaw skills info @owner/slug 直接看到这个技能的 description、依赖和来源，确认装到的就是你要的那一版；若装到了错误 owner 的同名技能，openclaw skills list 会列出来，方便发现并重装。

6. 安全扫描误报处理

如果 ClawHub 扫描误报，发布者可以申诉：

clawhub skill rescan @your-org/hello-world

rescan 会重新跑一遍扫描。如果你的 skill 确实只是用了 exec 调本地脚本（并非恶意），在提案说明里写清用途、必要时补充说明，多半能解掉误报。但如果是真有风险的操作，别指望靠 rescan 蒙混过关——扫描只是第一道关，用户侧还会自己 verify 和读源码。

四、可以复制的指令

# 安装 ClawHub CLI
npm i -g clawhub

# 登录
clawhub login

# 发布技能
clawhub skill publish ./path/to/hello-world

# 指定版本和 owner 发布
clawhub skill publish ./path/to/hello-world --version 1.0.1 --owner @your-org

# 同步
clawhub sync --all

# 用户安装
openclaw skills install @your-org/hello-world

# 校验信任信封
openclaw skills verify @your-org/hello-world

发布之后，建议补两条”作者自查”命令：openclaw skills list 确认技能出现在列表里，openclaw skills info @your-org/hello-world 确认 frontmatter 完全正确。它们和 ClawHub 侧的 verify 是不同视角——一个看”本地加载对不对”，一个看”远程信任齐不齐”。

五、实战案例

你写了一个 weekly-email skill，本地测试通过，想发布到 ClawHub。

目录：

weekly-email/
├── SKILL.md
├── scripts/
│   └── draft.sh
└── templates/
    └── weekly.md.tpl

SKILL.md：

---
name: weekly-email
description: Generate a weekly standup email draft from notes.
homepage: https://github.com/yourname/weekly-email
metadata: { "openclaw": { "requires": { "bins": ["python3"] } } }
---

# Weekly Email

When the user says "写周报", run `{baseDir}/scripts/draft.sh` and save the result to `~/drafts/weekly-<date>.md`.

发布步骤：

1. 本地测三遍：openclaw agent --message "写周报"。
2. 登录：clawhub login。
3. 发布：clawhub skill publish ./weekly-email --owner @yourname。
4. 自己安装验证：openclaw skills install @yourname/weekly-email。
5. 跑 openclaw skills verify @yourname/weekly-email 看信任信封是否正常。
6. 让同事安装并反馈。

如果 weekly-email 需要调用某个邮件服务的 API，别把密钥写进 SKILL.md 正文或脚本里。正确做法是在 openclaw.json 的 skills.entries.weekly-email.apiKey 里配置，或用 .env 注入——密钥走宿主进程的环境，不进 prompt、不进日志。这既是安全底线，也是”能放心发布”的前提。

六、常见误区

• 误区 1：发布了就等于自动升级用户的 skill。不会。用户要跑 openclaw skills update --all 才会拉新版本。
• 误区 2：description 随便写没关系。description 是用户在 ClawHub 发现你 skill 时第一眼看到的东西，写不好就没人装。
• 误区 3：不登录也能 publish。必须先 clawhub login。
• 误区 4：版本号随便填。建议遵循语义化版本，避免用户混淆。
• 误区 5：Git 和本地装的 skill 走 ClawHub update。不会，update --all 只跟踪 ClawHub 安装。从 Git 或本地装的要重新 install。
• 误区 6：只要发上去就有人信。信任信封和扫描是加分项，不是免死金牌。用户仍会读你的 SKILL.md、看脚本在做什么，作者该透明就透明。

七、进阶玩法

organization 发布：

你的团队可以申请 organization owner，比如 @your-company。组织里的 owner、admin、publisher 三个角色都能发布。这样 skill 属于团队资产，而不是绑定某个人。

和个人技能结合：

在共享 Gateway 上，已认证用户可以通过 Plugins → Skills → My skills 创建或导入 SKILL.md 或 ZIP。新托管技能归创建者所有，可以选择 Share with team 让别人使用，或 transfer to team 转为团队资产。

和 Skill Workshop 结合：

在 Workshop 里打磨好的提案，apply 后形成一个本地 skill，再 publish 到 ClawHub。这样发布前的每一版都有人审核。更新节奏上也有讲究：建议在 homepage 或 CHANGELOG 里写清每个版本的变动，用户跑 openclaw skills update --all 拉到新版后，能对照判断”这次更新有没有动到我依赖的行为”。版本只增不回退，真要修历史问题就发新版本，别指望用户手动回滚。

还可以把发布动作接进 CI：每次合并到主分支，自动跑 openclaw skills check + clawhub skill publish，让”提交即发布”可控地发生。注意这种方式要求 CI 环境已 clawhub login 且持有发布凭证，凭证同样要走安全的注入方式，不要明文写在流水线配置里。

八、小结

发布到 ClawHub 只需要三步：确保 SKILL.md 完整、安装 clawhub CLI 并登录、执行 clawhub skill publish。发布后要记得 verify 校验信任信封，并告诉用户用 openclaw skills install @owner/slug 安装。ClawHub 不只是分发渠道，它还是信任渠道：别人能通过扫描状态和版本记录判断这个 skill 可不可靠。把你的好 skill 发上去，是让价值放大的最快方式。