$ ~/registry/skill/openclaw-agents-skills-verify-release

SKILL

verify-release

Name: verify-release
Author: openclaw

Verify an OpenClaw release is fully published and working across all channels.

Stars

★ 382,582

Source

GitHub

Updated

2026-07-11

// securityCaution

Prompt only, no code
Open source
Community-trusted· 377.5k

Summary

This appears to be an open-source, prompt-only verification skill with no declared secrets or built-in remote endpoints, so the overall risk is low. The main caveat is that its workflow instructs the host agent to query GitHub, npm, and ClawHub and run verification commands, so runtime network and execution boundaries should still be controlled.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required. The README mentions 'Never print secrets' and 'Use inherited live keys' only as operating guidance, with no declared mechanism for the skill itself to collect, store, or exfiltrate credentials; as a prompt-only skill, its credential surface is small.

Network egressCaution

Although the system marks it as prompt-only and no built-in remote host is declared, the README explicitly requires live verification against the GitHub API, the npm registry, ClawHub, and related online release state. This is normal network use within the stated purpose, and there is no specific red flag showing exfiltration to unknown or unrelated endpoints.

Code executionCaution

The README contains many command-oriented verification steps such as `gh release view`, `npm view`, downloading tarballs, and `openclaw plugins install`, indicating that when used by a host agent it may drive local command execution and installation/verification flows. This is consistent with its release-verification purpose, and there is no sign of requesting unusual system privileges or stealth execution.

Data accessCaution

The documentation calls for reading release metadata, workflow results, and package information, and for unpacking tarballs or running smoke tests/plugin installs under `/tmp` and an isolated HOME. This scope is mainly limited to temporary directories and online release data, with no evident request for broad access to private user files, but it still involves local temporary files and environment-state access.

Supply chainLow risk

The source is an auditable open-source GitHub repository, the system flags it as open-source, and the community adoption is very high (about 377k stars), all of which materially lower supply-chain risk. The missing license declaration and unknown maintenance status are minor information gaps, but not enough to elevate this to high risk based on the provided material.

Recommendations

Constrain this skill to read-only verification use cases and avoid allowing it to automatically publish, upgrade, or perform unnecessary installs.
If you run the README commands, execute them in an isolated environment and restrict network access to required endpoints such as GitHub, npm, and ClawHub.
Apply least privilege and temporary-directory isolation to steps like `openclaw plugins install` and `npm exec` that fetch external packages.
Before production use, verify the repository license, recent maintenance activity, and key dependency pinning/locking.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "verify-release" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/verify-release/SKILL.md
2. Save it as ~/.claude/skills/verify-release/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Post-release end-to-end verification

Prompt

Verify whether OpenClaw v1.4.2 is fully published: check the GitHub Release, npm package, plugins, ClawHub, package smoke test results, and live Gateway agent turns, then produce an itemized status report and issue list.

Expected

A release verification report with per-channel status, pass/fail checks, discovered issues, and recommended next steps.

Identify missing release artifacts

Prompt

Check whether the latest OpenClaw release has any missing artifacts, especially whether npm, ClawHub, and plugin distribution are fully synchronized; if inconsistencies exist, identify the missing locations and likely causes.

Expected

A diagnostic summary showing which release channels are incomplete, what version mismatches exist, and the likely root causes.

Production availability confirmation

Prompt

Validate that this OpenClaw release is not only distributed but also usable: check smoke tests, live Gateway agent turn behavior, and summarize whether end users can install and invoke it successfully.

Expected

An availability confirmation summary stating whether the release is truly usable and listing any user-impacting risks.

// docs

Verify Release

Use this when asked whether an OpenClaw release is fully released, published, promoted, smoke-tested, or live-verified. This is a verification skill, not a publish skill; use $release-openclaw-maintainer before changing release state.

Rules

Resolve short suffixes like .27 to the concrete CalVer version from the current date/context, then say the resolved version.
Verify live state. Do not trust local checkout state, release notes, or old memory as current truth.
If the checkout is dirty or divergent, use it only for scripts/reference. For version metadata, fetch from GitHub release/tag or unpack the tag tarball under /tmp.
Never print secrets. Use inherited live keys only for scoped smoke commands.
Keep the final terse: yes/no, evidence bullets, caveats, cleanup.

Core Checks

GitHub release:
- gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
- Confirm stable releases are not draft/prerelease.
- Confirm release body has npm, CI, plugin npm, ClawHub, mac/appcast evidence links when expected.
- Confirm assets expected for stable mac releases are uploaded: zip, dmg, dSYM, dependency evidence when present.
Root npm:
- npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
- latest must equal <VERSION> for stable.
- Record tarball, integrity, publish time.
Plugin publish set:
- Get exact tag metadata from GitHub, not the local checkout when dirty: download https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> into /tmp/openclaw-v<VERSION>-src.
- Count extensions/*/package.json with openclaw.release.publishToNpm === true and openclaw.release.publishToClawHub === true.
- Compare expected counts to workflow job counts: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
- Each expected npm plugin must have version <VERSION> and dist-tags.latest === <VERSION>.
ClawHub:
- Check the Plugin ClawHub Release workflow conclusion and publish job count.
- Use OpenClaw itself for live registry proof: openclaw plugins search <known-plugin> --json.
- Install one official plugin from ClawHub in an isolated HOME: openclaw plugins install clawhub:@openclaw/matrix --pin. Prefer matrix unless that plugin is not in the expected set.
Release workflows:
- Verify conclusions for release notes evidence links: Full Release Validation, OpenClaw Release Checks, OpenClaw NPM Release, Plugin NPM Release, Plugin ClawHub Release, mac preflight/validation/publish when stable mac assets are expected.
- Summarize only relevant successful/failed jobs; ignore routine skipped optional lanes unless the release body promised them.
Published package smoke:
- In /tmp, isolated HOME: npm exec --yes --package openclaw@<VERSION> -- openclaw --version.
- Run at least one harmless command that touches the published CLI surface, for example plugins --help or gateway --help.
Dev Gateway live model smoke:
- Use temp HOME/workspace, not the user's normal state: HOME=/tmp/openclaw-release-smoke/home OPENCLAW_WORKSPACE=/tmp/openclaw-release-smoke/work pnpm openclaw --dev gateway run --auth none --force --verbose.
- Health check via CLI: openclaw --dev gateway health --json.
- Run one Gateway-backed agent turn with inherited OPENAI_API_KEY, short prompt, explicit session key, JSON output, and a known-available model.
- If the configured default model fails as unavailable, record that caveat and retry with the newest known-good OpenAI model instead of declaring the release failed.
- Stop the gateway and verify the port is not listening.

Caveats To Report

Dist-tag caveat: stable latest is release truth; if optional beta mirrors

…

View full docs ↗

Inspect, patch, validate, and publish OpenClaw GHSA advisories securely.

openclawGet→

$ loading_

Please install the "verify-release" skill from askskill: 1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/verify-release/SKILL.md 2. Save it as ~/.claude/skills/verify-release/SKILL.md 3. Reload skills and tell me it's ready

// examples

Post-release end-to-end verification

Prompt

Verify whether OpenClaw v1.4.2 is fully published: check the GitHub Release, npm package, plugins, ClawHub, package smoke test results, and live Gateway agent turns, then produce an itemized status report and issue list.

Expected

A release verification report with per-channel status, pass/fail checks, discovered issues, and recommended next steps.

Identify missing release artifacts

Prompt

Check whether the latest OpenClaw release has any missing artifacts, especially whether npm, ClawHub, and plugin distribution are fully synchronized; if inconsistencies exist, identify the missing locations and likely causes.

Expected

A diagnostic summary showing which release channels are incomplete, what version mismatches exist, and the likely root causes.

Production availability confirmation

Prompt

Validate that this OpenClaw release is not only distributed but also usable: check smoke tests, live Gateway agent turn behavior, and summarize whether end users can install and invoke it successfully.

Expected

An availability confirmation summary stating whether the release is truly usable and listing any user-impacting risks.

// docs

Verify Release

Rules

Resolve short suffixes like .27 to the concrete CalVer version from the current date/context, then say the resolved version.
Verify live state. Do not trust local checkout state, release notes, or old memory as current truth.
If the checkout is dirty or divergent, use it only for scripts/reference. For version metadata, fetch from GitHub release/tag or unpack the tag tarball under /tmp.
Never print secrets. Use inherited live keys only for scoped smoke commands.
Keep the final terse: yes/no, evidence bullets, caveats, cleanup.

Core Checks

GitHub release:
- gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
- Confirm stable releases are not draft/prerelease.
- Confirm release body has npm, CI, plugin npm, ClawHub, mac/appcast evidence links when expected.
- Confirm assets expected for stable mac releases are uploaded: zip, dmg, dSYM, dependency evidence when present.
Root npm:
- npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
- latest must equal <VERSION> for stable.
- Record tarball, integrity, publish time.
Plugin publish set:
- Get exact tag metadata from GitHub, not the local checkout when dirty: download https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> into /tmp/openclaw-v<VERSION>-src.
- Count extensions/*/package.json with openclaw.release.publishToNpm === true and openclaw.release.publishToClawHub === true.
- Compare expected counts to workflow job counts: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
- Each expected npm plugin must have version <VERSION> and dist-tags.latest === <VERSION>.
ClawHub:
- Check the Plugin ClawHub Release workflow conclusion and publish job count.
- Use OpenClaw itself for live registry proof: openclaw plugins search <known-plugin> --json.
- Install one official plugin from ClawHub in an isolated HOME: openclaw plugins install clawhub:@openclaw/matrix --pin. Prefer matrix unless that plugin is not in the expected set.
Release workflows:
- Verify conclusions for release notes evidence links: Full Release Validation, OpenClaw Release Checks, OpenClaw NPM Release, Plugin NPM Release, Plugin ClawHub Release, mac preflight/validation/publish when stable mac assets are expected.
- Summarize only relevant successful/failed jobs; ignore routine skipped optional lanes unless the release body promised them.
Published package smoke:
- In /tmp, isolated HOME: npm exec --yes --package openclaw@<VERSION> -- openclaw --version.
- Run at least one harmless command that touches the published CLI surface, for example plugins --help or gateway --help.
Dev Gateway live model smoke:
- Use temp HOME/workspace, not the user's normal state: HOME=/tmp/openclaw-release-smoke/home OPENCLAW_WORKSPACE=/tmp/openclaw-release-smoke/work pnpm openclaw --dev gateway run --auth none --force --verbose.
- Health check via CLI: openclaw --dev gateway health --json.
- Run one Gateway-backed agent turn with inherited OPENAI_API_KEY, short prompt, explicit session key, JSON output, and a known-available model.
- If the configured default model fails as unavailable, record that caveat and retry with the newest known-good OpenAI model instead of declaring the release failed.
- Stop the gateway and verify the port is not listening.

Caveats To Report

Dist-tag caveat: stable latest is release truth; if optional beta mirrors

…

View full docs ↗