| name | workclaw-release-readiness |
| description | Use when changes affect versioning, installer branding, release docs, packaging outputs, or vendor release lanes in WorkClaw before deciding a branch is ready to ship. |
WorkClaw Release Readiness
Overview
Use this skill for shipping-sensitive changes. It separates release readiness from ordinary code verification and produces a clear ship recommendation with evidence.
When to Use
- Version files or release metadata changed
- Installer branding or installer checks changed
- Release docs changed
- Packaging outputs or desktop build expectations changed
- Vendor lane or upstream sync release paths changed
- A branch is being assessed for ship readiness after release-sensitive work
Do not use this for ordinary feature work that does not touch release-sensitive surfaces.
Command Routing
- Run
pnpm release:check-version for version and release metadata changes.
- Run
pnpm test:release for release-path validation.
- Run
pnpm test:installer for installer branding or installer flow changes.
- Run
pnpm test:release-docs for release note or release document changes.
- Run
pnpm test:openclaw-vendor-lane for vendor sync or lane changes.
- Run
pnpm build:runtime when packaging output or desktop build behavior changed.
Required Output
- Release verdict:
GREEN, YELLOW, or RED
- Blocking issues, if any
- Required release-note or documentation follow-ups
- Final recommendation on whether the branch is safe to ship
Output Template
Use this shape:
## Release Readiness
- Verdict: GREEN | YELLOW | RED
- Changed release surface:
- Commands run:
- Blocking issues:
- Required follow-ups:
- Ship recommendation:
Core Pattern
- Identify which release-sensitive surface changed.
- Run the matching release commands.
- Start from "safe to ship" and only downgrade when there is concrete evidence.
- If blocked, provide an explicit unblock checklist.
Common Mistakes
- Treating release-doc or installer changes as low-risk and skipping dedicated checks.
- Reporting a release verdict without citing commands or evidence.
- Mixing ordinary runtime verification with ship-readiness judgment and losing the release signal.