OpenClaw Plugin Ship Gate

Deterministic go/no-go process for publishing OpenClaw plugins with evidence.

Positioning

Best for

• Shipping OpenClaw plugins to ClawHub with fewer submission failures
• Turning pre-publish checks into a strict release gate
• Producing exact dashboard fields from git without manual guesswork

Not for

• Publishing non-OpenClaw npm packages
• Deep runtime security auditing
• Blind auto-publish without human review

Differentiator

Unlike generic scaffold helpers, this skill enforces a release gate: it returns READY, BLOCKED, or UNCERTAIN based on check evidence, not optimism.

Runtime requirements

• Required binaries: git, jq
• Included scripts:
  • scripts/new-plugin.sh
  • scripts/plugin-preflight.sh
  • scripts/plugin-release-fields.sh

If required binaries are unavailable, report UNCERTAIN and provide remediation.

Operating modes

Mode 1) Scaffold

./scripts/new-plugin.sh <plugin-slug> [target-dir]

Creates baseline plugin files:

• package.json
• openclaw.plugin.json
• index.js

Scaffold is never publish-ready by itself. Always run preflight next.

Mode 2) Preflight (mandatory gate)

./scripts/plugin-preflight.sh <plugin-dir>

Checks:

• required files and JSON validity
• required manifest keys
• OpenClaw compatibility/build metadata
• version alignment between manifests
• quality signals (description, README.md)
• risk-pattern warnings (child_process, execSync, spawn)

Treat every [error] as a hard release blocker.

Mode 3) Release fields packet

./scripts/plugin-release-fields.sh <repo-dir>

Returns dashboard-ready fields:

• source repo
• source commit
• source ref
• changelog starter text

If git metadata is missing, verdict is BLOCKED.

Response contract

When this skill is used, return results in this structure:

1. Verdict: READY | BLOCKED | UNCERTAIN
2. Why: brief reason (1-3 lines)
3. Evidence: check-by-check status (pass/warn/fail/skipped)
4. Blockers: exact issues and exact fixes
5. Publish packet (only if READY): repo/commit/ref/changelog
6. Next single action: best immediate step

Avoid long narrative unless asked.

Decision policy

Set verdicts strictly:

• READY only when:

  • preflight has no [error]
  • required publish fields are present
  • required checks actually ran

• BLOCKED when:

  • any preflight [error] exists
  • required manifest fields are missing
  • versions mismatch
  • required git publish fields are missing

• UNCERTAIN when:

  • required checks could not run (missing jq, inaccessible repo, command failure)
  • evidence is incomplete

Never claim READY from assumptions.

Safety and trust guardrails

• Never fabricate check outputs.
• Never hide skipped checks.
• Never claim security guarantees beyond executed checks.
• Never auto-publish or imply publish success.
• If repo URL contains embedded secrets/tokens, require sanitization before sharing.

60-second happy path

./scripts/new-plugin.sh my-plugin ./plugins
./scripts/plugin-preflight.sh ./plugins/my-plugin
./scripts/plugin-release-fields.sh ./plugins/my-plugin

Then submit in ClawHub Dashboard -> Publish Plugin.

Minimal troubleshooting

1. Missing files -> regenerate scaffold or add required files.
2. JSON parse errors -> fix syntax and rerun preflight.
3. Version mismatch -> align versions in both manifests.
4. Missing git fields -> set origin, commit changes, confirm branch.
5. Risk warnings -> inspect/refactor flagged runtime patterns before publish.