ClawHub：OpenClaw 技能與插件的公開註冊表，軟刪除與重定向是它的關鍵設計

它解決的是技能散落的問題，而不是技能本身的問題

OpenClaw 使用者過去要分享一個技能，多半是把 SKILL.md 丟到某個 repo 或貼在 Discord。ClawHub 把這件事變成一個公開註冊表，讓技能有版本、有 changelog、有標籤，也能被搜尋。它同時涵蓋程式碼插件、bundle 插件與實驗性的整機 Claw 套件。這個專案不是給你寫技能的，而是給你在技能寫完之後，發布、追蹤、安裝與撤銷的地方。它的目標對象是 OpenClaw 的進階使用者，以及想要經營技能生態系的團隊。如果你根本不用 OpenClaw，那這個專案對你沒有任何意義。

向量搜尋是亮點，但依賴 OpenAI 是取捨

ClawHub 的搜尋不是靠關鍵字比對，而是用 OpenAI 的 text-embedding-3-small 產生 embeddings，再交給 Convex 的向量搜尋。這表示搜尋結果可以捕捉語意相近但字面不同的技能描述，比傳統的 grep 或 tag 比對更靈活。但這也代表索引與搜尋都需要呼叫 OpenAI API，每次發布技能或執行搜尋都會產生費用與延遲。README 沒有提到離線或自託管 embeddings 的選項，所以如果你在隔離環境或不想把技能描述送出外部服務，這會是一個硬限制。對一個號稱 CLI-friendly 的註冊表來說，這種外部依賴讓它無法在完全離線的環境運作。

軟刪除與重定向：設計上比硬刪除更謹慎

ClawHub 對已上傳的技能採用軟刪除，也就是 clawhub delete 只會隱藏，不會真正移除資料。恢復用 clawhub undelete，而且只有技能擁有者、發布者管理員、moderator 與 admin 有權限。硬刪除則僅限 admin，用於管理工具或封鎖流程。這個設計很實際，因為技能一旦被安裝，使用者可能依賴舊版，硬刪除會破壞他們的環境。另外，技能改名時，舊 slug 會保留為重定向別名；合併技能時，來源 slug 也會重定向到 canonical 目標。這表示你發布的連結不會因為改名或合併而失效。對一個公開註冊表來說，這是重要的相容性承諾，但也讓資料模型更複雜，因為你需要處理別名與軟刪除狀態。

CLI 操作直觀，但安裝與發布的權限界線要分清楚

CLI 提供完整的流程：登入用 clawhub login，裝置授權用 --device，搜尋用 clawhub search，發布技能用 clawhub skill publish <path>，發布插件用 clawhub package publish <source>。本機安裝管理有 install、pin、unpin、uninstall、list、update --all。這裡有一個容易混淆的地方：clawhub uninstall 只移除本機安裝，不會影響註冊表上的記錄。要移除已發布的技能，必須用 clawhub delete，那是軟刪除。這個區分在 README 寫得很清楚，但對新手來說，可能會誤以為 uninstall 就能撤銷發布。另外，pin 可以防止更新或強制重裝覆蓋冷凍的副本，這對需要鎖定版本的使用者很有用。整體來說，CLI 的命名與動作相當一致，學習成本不高。

Nix 插件支援是特定族群的殺手級功能

ClawHub 可以在 SKILL.md 的 frontmatter 中儲存一個 nix-clawdbot 插件指標，讓註冊表知道要安裝哪個 Nix package bundle。這不是一般的技能包，它把技能包、CLI 二進位檔、以及 config flags 與 requirements 綁在一起。例如，metadata.clawdbot.nix.plugin 可以指向 github:clawdbot/nix-steipete-tools?dir=tools/peekaboo，並指定 systems 為 aarch64-darwin。安裝時透過 nix-clawdbot 的 programs.clawdbot.plugins 設定即可。這對使用 NixOS 或 nix-darwin 的使用者來說非常方便，因為技能依賴的系統工具可以直接由 Nix 管理。但這也意味著，如果你不用 Nix，這個功能對你沒有價值，而且 frontmatter 中多了這些 metadata，可能會讓非 Nix 使用者感到困惑。

本地開發需要 Bun、Convex 與一堆環境變數

要跑起這個專案，你需要 Bun，Convex 可以透過 bunx 執行，不需要全域安裝。步驟是 bun install、複製 .env.local.example 為 .env.local，然後開兩個終端：一個跑 bunx convex dev，另一個跑 bun run dev。環境變數包括 VITE_CONVEX_URL、VITE_CONVEX_SITE_URL、SITE_URL、GitHub OAuth 的 AUTH_GITHUB_ID 與 AUTH_GITHUB_SECRET、Convex Auth 的 JWT_PRIVATE_KEY 與 JWKS，以及 OPENAI_API_KEY。還有一個 seed 指令 bun run seed:dev，會等待本地 Convex 部署、執行 fixture seed 並重新整理全域統計。這表示你要完整測試，必須同時設定 GitHub OAuth 與 OpenAI 金鑰，這對只想快速試用的人來說門檻不低。如果你只是要使用 clawhub CLI 連到公開站台，那不需要這些；但若要開發或部署自己的實例，這些都是必要的。

遙測與授權：安裝時會回傳資料，但可以關閉

ClawHub 在登入狀態下執行 clawhub install 時，會追蹤最少的安裝遙測，用來計算安裝次數。這對發布者來說是重要的統計數據，但對注重隱私的使用者可能是疑慮。你可以用 export CLAWHUB_DISABLE_TELEMETRY=1 關閉，這是明確的選項，值得肯定。授權是 MIT，這表示你可以自由修改與再發布，但要注意，如果你自己部署一個實例，你仍然需要處理 Convex 與 OpenAI 的費用。遙測資料的細節在 docs/telemetry.md，但 README 沒有說明資料保留多久或是否可被刪除。如果你打算在自己的組織內部部署，這點需要先確認。

替代方案：本機技能管理與 git 才是真正的對手

ClawHub 的替代方案不是另一個註冊表，而是你自己用 git 管理技能。你可以在一個 repo 放所有 SKILL.md，用 git tag 做版本，用分支做實驗，用 pull request 做審核。這種方式沒有向量搜尋，沒有軟刪除，也沒有安裝計數，但完全離線、零外部依賴、免費。ClawHub 的價值在於集中發現與發布，但如果你只是個人使用，或團隊規模小到可以直接用檔案系統，那麼 git 的簡單性遠勝過 Convex 的複雜性。另一個角度是，ClawHub 本身是建在 Convex 上，所以如果你想自託管，你必須自己營運 Convex 部署，這比跑一個靜態網站或單一服務更重。對比之下，git repo 的維護成本幾乎是零。

編輯結論

ClawHub 適合已經使用 OpenClaw、需要集中發布與發現技能或插件的團隊，尤其是那些重視版本追蹤、軟刪除恢復與重定向相容性的使用者。不適合只在本機管理少量技能、不想引入 Convex 部署或 OpenAI 依賴的個人開發者，因為你必須自行託管後端並承擔 embeddings 成本。採用前請先驗證三件事：你的 OpenClaw 版本是否相容於 clawhub CLI 的 pluginApi 與 openclawVersion 欄位，你的 GitHub OAuth 與 JWT 設定是否正確，以及你是否接受安裝遙測（可透過 CLAWHUB_DISABLE_TELEMETRY=1 關閉）。若你只需要本機技能管理，ClawHub 的軟刪除與重定向設計反而增加複雜度，不如直接使用檔案系統與 git。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes