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 CI is green. Then branch from that commit so regular development can continue on while release validation runs.