Keep these version fields aligned before creating a release:
package.jsonopenclaw.plugin.json
Use:
npm run release:version -- 0.0.3This updates both files to the same semantic version.
Run the full local validation path before tagging:
npm run checkCreate the packaged release zip locally:
npm run build
npm run release:packThis writes:
release/claw-guard-v<version>.zip
The build output under dist/ is a self-contained plugin root for local
development. It includes:
package.jsonopenclaw.plugin.jsonindex.js- runtime subdirectories and dashboard assets
The release zip reuses that same plugin-root layout under a top-level
claw-guard/ folder.
The dist/package.json and packaged package.json are generated from the
development manifest and keep
only release-safe fields needed for loading:
nameversiondescriptiontypemainenginesopenclaw
Development-only fields such as scripts, devDependencies, and files are
intentionally excluded from the archive manifest.
The release archive content is also filtered for release use:
- keep runtime
.js,.json, and asset files - exclude
*.test.* - exclude
*.map - exclude
*.d.ts*
The packaged package.json must keep openclaw.extensions pointed at
./dist/index.js for npm/archive installs handled by OpenClaw.
The GitHub Actions workflow in .github/workflows/release.yml publishes automatically when a version tag is pushed.
Release flow:
git add package.json openclaw.plugin.json package-lock.json
git commit -m "Release v0.0.3"
git tag v0.0.3
git push origin main
git push origin v0.0.3When the v0.0.3 tag reaches GitHub, Actions will:
- install dependencies with
npm ci - run
npm run build - package the plugin root as
claw-guard-v0.0.3.zip - create or update the corresponding GitHub Release
- upload the zip as a release asset
If a tag already exists and you need to republish from GitHub Actions manually:
- open the Actions tab
- run
Release Claw Guard - provide the existing tag, for example
v0.0.3