OpenClaw Release Maintainer

Use this skill for release and publish-time workflow. Load $release-private if it exists before resolving Peter-owned credential locators or private host topology. Keep ordinary development changes and GHSA-specific advisory work outside this skill.

Respect release guardrails

• Do not change version numbers without explicit operator approval.
• Ask permission before any npm publish or release step.
• This skill should be sufficient to drive the normal release flow end-to-end.
• Use the private maintainer release docs for credentials, recovery steps, and mac signing/notary specifics, and use docs/reference/RELEASING.md for public policy.
• Core openclaw publish is manual workflow_dispatch; creating or pushing a tag does not publish by itself.
• Normal release work happens on a branch cut from main, not directly on main. Use release/YYYY.M.D for the branch name.
• If the operator asks for a release without saying stable/full, default to beta only. Continue from beta to stable only when the operator explicitly asks for the full release or an automated beta-and-stable train.
• Before release branching, pull latest main and confirm current main CI is green. Then branch from that commit so regular development can continue on main while release validation runs.
• Before release branching, commit any dirty files in coherent groups, push, pull/rebase, then generate CHANGELOG.md on main from merged PRs and all direct commits since the last reachable release tag. Commit/push/pull that changelog rewrite immediately before creating the release branch.
• During release planning, inspect both src/plugins/compat/registry.ts and src/commands/doctor/shared/deprecation-compat.ts before branching and again before final publish. For every deprecated or removal-pending compatibility record whose removeAfter date is on or before the release date, either remove the compatibility path where safe and validate the affected tests, or write down why removal is blocked and get explicit maintainer approval before shipping the expired compatibility path.
• When removing deprecated runtime/config compatibility, preserve any doctor migration, repair, or hint that is still needed by supported upgrade paths. Doctor-side compatibility should stay tracked in src/commands/doctor/shared/deprecation-compat.ts until maintainers confirm the repair is no longer needed.
• Revalidate compatibility replacement text during release planning. The recommended replacement can shift as plugin ownership, externalization, and config footprint move, so do not blindly copy stale replacement annotations into release notes.
• Do not delete or rewrite beta tags after their matching npm package has been published. If a pushed beta tag fails before npm publish, the version is not consumed: keep the same -beta.N, delete/recreate or force-move the git tag and prerelease to the fixed commit, and rerun preflight. Do not increment to the next beta number until the matching npm package has actually published. If a published beta needs a fix, commit the fix on the release branch and increment to the next -beta.N.
• For a beta release train, keep Full Release Validation as a pre-publish gate unless the operator explicitly waives it. Run the fast local preflight, npm preflight, full release validation, and performance in parallel where safe. If anything fails before npm publish, fix it on the release branch, forward-port the fix to main, move the unpublished beta tag/prerelease to the fixed commit, and rerun the affected pre-publish gates. If anything fails after npm publish, fix it, forward-port to main, increment beta number, and repeat. After each beta publish, run the published-package roster focused on install/update/Docker/Parallels/NPM Telegram. For later beta attempts, rerun

…