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 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 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/.
2. Confirm it has already been reviewed and committed locally.
3. Inspect remote state with clawhub inspect .
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 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:

node scripts/publish_to_clawhub.js --skill-path <path> --slug <slug> --version <version> --changelog <text>

Optional:

--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.