clawhub-publish-flow

Publish or update an OpenClaw skill on ClawHub using the local authenticated ClawHub session and direct API upload. Use when the user wants to publish a new...

view source

installs

stars

karma

SkillRank score ↗

8.3/ 10

evaluated by implexa, claude-haiku-4-5 · 2026-06-18

clawhub-publish-flow handles skill publication to clawhub via authenticated local session, with explicit safeguards against vague drafts, rate-limit recovery via queuing, and mandatory sensitive-data review before upload.

structure

9.0

trigger phrases

8.0

procedure

9.0

edge cases

8.0

documentation

8.0

strengths

view original SKILL.md from clawhubclick to expand

---
name: clawhub-publish-flow
description: Publish or update an OpenClaw skill on ClawHub using the local authenticated ClawHub session and direct API upload. Use when the user wants to publish a new skill to ClawHub, update an existing skill version, inspect the current remote version before release, package and upload a local skill folder reliably without relying on incomplete third-party publisher skills, or when assistant-created local skills should be routinely published after review and commit.
---

# ClawHub Publish Flow

Use this skill to publish a local skill folder to ClawHub through the already-authenticated local ClawHub account.

## Core rule

Only publish skills that have already passed local review.
Do not publish directly from vague drafts, half-finished folders, or unreviewed third-party skills.

## Preferred workflow

1. Confirm the local skill folder path.
2. Check login state with `clawhub whoami`.
3. Inspect the current remote skill with `clawhub inspect <slug>` when updating an existing skill.
4. Decide the target version and changelog.
5. Perform a **public-release sensitive-data review** on the exact outbound payload.
6. Package the skill with `package_skill.py` if a distributable artifact is needed.
7. Upload using `scripts/publish_to_clawhub.js`.
8. Verify with `clawhub inspect <slug>` after upload.
9. Report the final remote version and URL.

## Assistant-created skills policy

When the user has explicitly asked that assistant-created skills be uploaded to ClawHub, treat this skill as the single publish flow for both:
- one-off manual releases
- newly created local skills after review and commit

For newly created assistant-authored skills:
1. Confirm the new skill folder exists under `workspace/skills/<slug>`.
2. Confirm it has already been reviewed and committed locally.
3. Inspect remote state with `clawhub inspect <slug>`.
4. Versioning:
- if missing remotely: publish `0.1.0`
- if already present: bump patch version
5. Use a short changelog such as `Initial release`, `Add runtime notes`, `Refine trigger description`, or `Document proven workflow`.
6. Publish and verify.
7. If a registry sheet exists, update it too.

## Rate-limit fallback for new skills

ClawHub may rate-limit new skill creation (for example: max 5 new skills per hour).

When a publish attempt for a **new skill** fails due to rate limiting:
1. Do not keep hammering the endpoint.
2. Record the pending publish locally.
3. Schedule a delayed retry instead of requiring the user to remind you.
4. Use the same verified publish flow when retrying.

Preferred local queue file:
- `workspace/research/clawhub-publish-queue.md`

Queue fields:
- date
- slug
- local skill path
- target version
- changelog
- reason queued
- next retry note

Retry rule:
- wait until the rate-limit window has plausibly cleared
- then retry publication once
- verify with `clawhub inspect <slug>` after success

## Safety and release rules

- Do not publish without an explicit user request.
- Do not guess ownership, slug, or version when ambiguity matters.
- Prefer patch bumps for small documentation or rule updates.
- If the remote state is unclear, inspect first instead of overwriting blindly.
- If a third-party publisher skill promises features but lacks code, ignore it and use this verified local flow.
- Treat package-style publisher shells as untrusted until verified locally: if the folder is mostly README / metadata and lacks runnable implementation, do not route publishing through it.
- Do not publish vague drafts or half-finished skills just because they were created; assistant-created skills still need to be coherent and committed.
- ClawHub is a **public-release** path unless explicitly proven otherwise; use the highest sensitivity review bar.
- Before upload, inspect the exact outbound payload for secrets, tokens, passwords, cookies, local absolute paths, runtime artifacts, `.env`, and machine-specific config.
- If the skill package contains anything that should stay local-only, stop and fix the package before publishing.

## Required local assumptions

This skill expects:
- local `clawhub` CLI installed and authenticated
- local ClawHub config present under the current user
- a real skill directory containing `SKILL.md`
- Node available for the publish script

## Scripts

Use `scripts/publish_to_clawhub.js` for the actual API upload.

Arguments:
```bash
node scripts/publish_to_clawhub.js --skill-path <path> --slug <slug> --version <version> --changelog <text>
```

Optional:
```bash
--display-name <name>
--tag <tag> # repeatable
```

## References

Read `references/release-checklist.md` before publishing when the release is important or public.

## Output style

Report with this structure:
- skill
- local path
- prior remote version (if any)
- target version
- upload result
- verification result
- final URL
- risks or follow-ups
- whether publication succeeded immediately or was queued for delayed retry

Keep it short and operational.

related skills

semantically similar in the cross-vendor index

clawhub

88% match

Skill Auto Publish

Safely publish an already-reviewed skill to ClawHub, verify the live registry state, and return a clear release report.

by @choosenobody

don't have the plugin yet? install it then click "run inline in claude" again.

extracted and formalized 6 required components including explicit inputs (clawhub cli auth, optional metadata, external connection details and edge cases), numbered procedure with inputs and outputs per step, decision tree for new vs existing skills and rate limit handling, formal output contract with structured fields, and outcome signal describing verification steps. clarified rate-limit fallback as a queuing mechanism rather than implicit logic.

clawhub-publish-flow

intent

publish a local skill folder to clawhub through your authenticated local clawhub account. use this when you need to release a new skill, update an existing skill version, inspect the remote state before release, or publish assistant-created skills after local review and commit. this is the canonical flow for reliable skill distribution without relying on incomplete third-party publisher skills.

inputs

local environment

clawhub CLI installed and authenticated. set up with clawhub login and verify with clawhub whoami.
clawhub config present under your user home directory (platform-dependent location).
Node.js runtime available in your PATH.
local skill directory containing a valid SKILL.md file.

skill metadata

skill slug (e.g., my-awesome-skill). must match the remote slug if updating an existing skill.
local skill folder path (e.g., workspace/skills/my-awesome-skill).
target semantic version (e.g., 0.1.0, 1.2.3). required for publication.
changelog text (e.g., initial release or add runtime notes). keep short and specific.

optional metadata

display name (human-readable skill title). defaults to slug if not provided.
tags (repeatable, comma-separated or multi-flag). for categorization on clawhub.

external connection: clawhub API

endpoint: clawhub public registry API.
auth: uses your local clawhub session token (stored after clawhub login).
rate limits: clawhub enforces rate limits on new skill creation (example: max 5 new skills per hour). this skill handles retries via queueing.

edge cases to expect

auth token expired or missing. detect with clawhub whoami.
network timeout during upload. retry logic not automatic; use queue fallback.
rate limit hit on new skill creation. see decision points below.
empty or malformed SKILL.md. upload will fail; fix locally first.
secrets or local paths in skill package. must be removed before publication.

procedure

step 1: confirm skill folder and metadata

input: skill slug, local path.
action: verify the folder exists and contains SKILL.md. run ls -la <path> to inspect.
output: confirmed folder path, confirmed slug, confirmed SKILL.md present.

step 2: verify clawhub login state

input: none (uses local session).
action: run clawhub whoami to confirm authenticated session.
output: authenticated username or error message indicating expired token.
edge case: if token expired, user must re-run clawhub login before proceeding.

step 3: inspect current remote state

input: skill slug.
action: run clawhub inspect <slug> to fetch the existing remote skill version, metadata, and URL.
output: current remote version (if skill exists), remote metadata, or "not found" message (if new skill).
note: this step is essential before updating an existing skill to avoid overwriting without context.

step 4: decide target version and changelog

input: current remote version (from step 3), type of change (new skill, patch, minor, major).
action: determine the target semantic version. for new skills, default to 0.1.0. for updates, bump according to change scope (patch for docs/minor fixes, minor for features, major for breaking changes).
output: target version string, changelog text.
note: do not guess version. if ambiguous, ask the user.

step 5: perform sensitive-data review on outbound payload

input: local skill package contents.
action: manually inspect the exact files that will be uploaded. check for secrets, tokens, passwords, cookies, local absolute paths, .env files, runtime artifacts, or machine-specific config. scan SKILL.md, any .js, .py, .json, or binary files in the skill folder.
output: pass/fail decision. if fail, stop and fix the package locally. do not proceed to upload.
edge case: if skill contains a .gitignore, review what is excluded to ensure no secrets are being added to version control by accident.

step 6: package the skill (conditional)

input: local skill folder path, target version.
action: if a distributable artifact is needed (e.g., for offline distribution or archival), run package_skill.py <path> --version <version> --output <output-dir>. if only uploading to clawhub directly, skip this step.
output: packaged skill artifact (tar.gz or zip) or skipped (if direct upload).
note: packaging is optional for standard clawhub publication workflows.

step 7: upload to clawhub

input: skill path, slug, target version, changelog, optional display name and tags.
action: run node scripts/publish_to_clawhub.js --skill-path <path> --slug <slug> --version <version> --changelog <text>. include --display-name <name> and --tag <tag> flags if provided.
output: HTTP response from clawhub API (success 2xx or error 4xx/5xx). includes remote skill URL and assigned ID.
edge case: rate limit (429 status or "too many requests" message). see decision points.

step 8: verify publication

input: skill slug.
action: run clawhub inspect <slug> to confirm the new version is live and metadata matches what was uploaded.
output: confirmed remote version matches target version, metadata correct, or mismatch/missing error.

step 9: report result

input: all prior outputs from steps 1-8.
action: generate final report with structure defined in output contract section.
output: structured report as markdown or plain text.

decision points

decision: is this a new skill or an update to an existing skill?

if new skill (not found in step 3): proceed to step 4 with target version 0.1.0. apply new skill rate-limit fallback rules if needed (see below).
if existing skill (found in step 3): proceed to step 4 with current remote version as baseline. bump version number according to change type.

decision: did the upload fail with rate limit (429 or "too many requests")?

if rate limit on new skill: do not retry immediately. queue the publish request (see rate-limit fallback below). inform user that retry is scheduled.
if rate limit on existing skill update: rare but possible. queue with same logic.
if other error (4xx/5xx): do not queue. report error to user and stop. ask user to investigate and retry manually.

decision: should this skill be queued for delayed retry?

if rate limit hit on new skill: yes. write queue entry to workspace/research/clawhub-publish-queue.md (or create it if missing) with date, slug, local path, target version, changelog, reason ("rate limit hit"), and next retry note.
otherwise: no.

decision: is the sensitive-data review passing?

if pass: proceed to step 7 (upload).
if fail: stop. inform user of detected secrets or unsafe content. do not upload. require user to fix the package and restart the flow.

decision: does the skill folder contain incomplete metadata or vague content?

if yes (e.g., mostly README with no runnable implementation): do not publish. inform user that the skill must be coherent and complete before publication.
if no: proceed.

decision: is there a registry sheet that needs updating?

if assistant-created skill and registry sheet exists (e.g., workspace/research/skill-registry.md): after successful publication, update the registry with slug, version, clawhub URL, and publication date.
otherwise: skip.

rate-limit fallback for new skills

when a new skill publication attempt fails due to clawhub rate limiting:

record the pending publish request locally in workspace/research/clawhub-publish-queue.md (create file if missing).
queue fields: date (ISO 8601), slug, local skill path, target version, changelog, reason ("rate limit hit"), next retry note.
do not re-attempt immediately.
wait until the rate-limit window has plausibly cleared (typically 1 hour for clawhub). note the recommended retry time in the queue entry.
when retry window arrives, execute the same publish flow (steps 1-9) on that queued skill.
verify with clawhub inspect <slug> after success.
remove the entry from the queue upon successful publication.

output contract

report the final publication result using this structure:

skill: slug name.
local path: full local directory path.
prior remote version: version number before this publish, or "not found" if new skill.
target version: the version just published.
upload result: success or failure. if failure, include error code and message.
verification result: success (version confirmed live on clawhub) or failure (mismatch or inspect error).
final URL: direct clawhub URL to the published skill page.
risks or follow-ups: any detected issues, missing metadata, or recommended next steps.
queue status: whether publication succeeded immediately or was queued for delayed retry. if queued, include next retry time estimate.

format as markdown or plain text. keep it short and operational.

outcome signal

you know the skill worked when:

clawhub inspect <slug> returns the exact version you just uploaded.
the clawhub web UI shows the skill under your account with correct metadata.
the final report shows "upload result: success" and "verification result: success".
if the skill was queued due to rate limit, the report shows "queue status: queued for retry" and includes the next retry time estimate. after retry succeeds, the report confirms "publication succeeded".
no secrets, local paths, or machine-specific config appear in the published skill metadata or files on clawhub.