Publish to ClawHub
James looked at his terminal. Nine tools, all tests green, payment working, identity loaded, routing configured, validation in place. The product existed, but only on his machine.
"It works," James said. "For me. What about everyone else?"
Emma pulled up clawhub.ai. "ClawHub. OpenClaw's public registry. You package what you built and publish it."
"Like an app store?"
"Similar. But you are not uploading your server code. You are publishing the instructions for connecting to it." She pointed at his project directory. "Your server runs on your machine. ClawHub tells other people how to reach it. The configuration, the shim skill, the identity. Not the code, not the data, not the keys."
"So publishing is packaging the connection instructions, not the product itself."
"The product IS the running server. ClawHub distributes the map to find it."
You are doing exactly what James is doing. Your product is complete. Now you package it and make it available to other OpenClaw users.
Understand What ClawHub Distributes
| Published to ClawHub | Stays on Your Machine |
|---|---|
| MCP server connection config (URL, transport) | The actual MCP server code (Python project) |
| Shim skill (SKILL.md) | JSON state files (learner data) |
| Agent identity (SOUL.md, IDENTITY.md) | Content files (chapters, exercises) |
| AGENTS.md (orchestration instructions) | Stripe keys, webhook secrets, .env |
ClawHub distributes configuration. Your server runs on your machine. Other users install the config that tells their OpenClaw instance how to connect to your server. Same model as MCP itself: the protocol connects clients to servers, but servers live wherever the developer runs them.
Your Stripe keys, learner data, and server source code never leave your machine. If you accidentally include a file with secrets, clawhub package create warns you before publishing.
Create the Package Manifest
The manifest tells ClawHub what TutorClaw includes. Ask Claude Code:
Create a ClawHub package manifest for TutorClaw in my
project root. Name: tutorclaw, version 1.0.0. Include
the MCP server connection config (streamable-http), the
shim SKILL.md from Lesson 16, SOUL.md and IDENTITY.md
from Lesson 17, and AGENTS.md from Lesson 9. Requirements:
OpenClaw 2.0+, Python 3.11+, Stripe account.
Review the manifest. Verify it references:
- MCP server config with your streamable-http URL
- Shim skill SKILL.md (Lesson 16)
- SOUL.md and IDENTITY.md (Lesson 17)
- AGENTS.md (Lesson 9)
A manifest that omits the shim skill publishes a package that breaks when the server goes offline. A manifest that omits AGENTS.md publishes tools without orchestration instructions.
Package the Components
clawhub package create tutorclaw
This collects the files from your manifest into a publishable package without uploading anything. If the command reports missing files, check the paths in your manifest. Capitalization matters: SKILL.md is not skill.md.
Output: A confirmation listing every included component. Verify: no server source code, no JSON state files, no .env variables.
Publish
clawhub publish tutorclaw
Your package appears on clawhub.ai. Other OpenClaw users install it with:
clawhub install tutorclaw
That command configures their OpenClaw instance with your MCP server connection, loads the shim skill, applies the agent identity, and sets up AGENTS.md orchestration. But the tools only work when your server is running, because the server lives on your machine.
Verify Your Own Package
Install your own package on a second agent profile or test environment:
clawhub install tutorclaw
openclaw gateway restart
Check three things from the dashboard:
1. MCP tools. Are all 9 tools listed under the TutorClaw server? If not, the connection config may have the wrong URL or transport.
2. Shim skill. Stop your MCP server. Send a study message. The agent should respond with PRIMM-Lite methodology from the shim. Generic response means the shim was not included.
3. Identity. Send "Who are you?" The agent should respond as TutorClaw. Default agent response means identity files were not included.
All three verified? Your package is complete. Restart your server after testing the shim.
Try With AI
Exercise 1: Classify Every File
Look at my tutorclaw-mcp project directory. For each file,
classify it as "published to ClawHub" or "stays private."
Explain the reasoning for any file where the classification
is not obvious.
What you are learning: The public/private boundary applies to any software distribution. Practicing this classification builds the habit of asking "should this be distributed?" before publishing.
Exercise 2: Diagnose a Broken Install
Another OpenClaw user installed TutorClaw from ClawHub.
The tools appear in the dashboard, but every tool call
returns an error. The shim skill works fine. Walk me
through the diagnostic process and the most likely cause.
What you are learning: The most common install failure is that the MCP server is not running on the developer's machine. Diagnosing this teaches the difference between distribution (ClawHub's job) and availability (your job as the server operator).
James ran clawhub publish tutorclaw. The listing appeared on clawhub.ai. He installed his own package on a test profile. Dashboard showed 9 tools. He stopped the server, sent a message, got PRIMM-Lite from the shim. Restarted the server, asked "Who are you?" and got TutorClaw's voice back.
"I published a product," he said.
Emma walked over. "You published a product that took five days to build. Nine tools, payment flow, identity, tests, hardening." She paused. "Most of that time was design and testing, not coding."
"Claude Code wrote the code. I described what I wanted."
"Right. The coding was the fast part. The hard parts were the specifications, the descriptions, the identity, and the tests. Those were your decisions." She pulled up the listing on her phone. "I should tell you something. I have shipped three agent products through private channels. Internal tools for teams I worked with. But I have never published publicly on ClawHub."
"Never?"
"Publishing to a private team is one thing. You know the users. You can walk over and fix problems." She set her phone down. "Publishing publicly is different. You are accountable to strangers. That changes how you think about error messages, documentation, and reliability."
James looked at his server terminal. "The server has to stay up."
"It does. And that is the next conversation. We audit the whole thing against the original blueprint. Every design decision from Lesson 2, checked against what actually got built."