release-openclaw-maintainer

Files (13)

• SKILL.md
• backport-discovery.md · references/
• extended-stable-backports.md · references/
• extended-stable-publish.md · references/
• first-package.md · references/
• platform-publication.md · references/
• preparation.md · references/
• publication-recovery.md · references/
• regular-release.md · references/
• release-handoff-template.md · references/
• retrospective.md · references/
• stable-main-closeout.md · references/
• validation.md · references/

SKILL.md (first lines)

# OpenClaw Release Maintainer

Use for a release operation, not ordinary development or advisory mutation.
Read `docs/reference/RELEASING.md` for current policy. Load `$release-private`
when available before resolving private credential locators or host topology;
credential operations use `$one-password`.

## Choose the role

- **Release owner (default):** “Manage this release” owns one release from
  preparation through verification, retrospective, and closeout. Start with
  [the owner lifecycle](references/release-owner.md), even for a short prompt.
- **Release manager / orchestrator:** coordinate several release owners, draft
  their kickoff or handoff briefs, and route hotfix opportunities. Start with
  [manager mode](references/release-manager.md). This role does not become a
  second writer of an owner's release branch or publication state.

The skill owns the general process; the initial prompt carries release-specific
intent, authority, and state, not a copied runbook. A handoff resumes that intent
with current evidence rather than starting another release.

## Choose the operation

Read only the references needed for the selected phase:

- Regular beta/stable preparation or publication: [regular release](references/regular-release.md), which routes preparation and phase-specific proof. If the request does not specify stable/full, default to beta; beta authorization does not authorize later stable promotion.
- Backport discovery and porting: [candidate inventory and worker brief](references/backport-discovery.md). For extended-stable also read [backport preparation](references/extended-stable-backports.md); SDK/config changes need a visible maintenance-risk warning and maintainer decision.
- Extended-stable `.33+` Gateway publication: [extended-stable publication](references/extended-stable-publish.md). Use the shared publisher with extended-stable inputs; its non-Latest GitHub Release carries evidence without native-app or ClawHub publication.
- Validation selection or failed proof: [validation and confidence](references/validation.md), with `$release-openclaw-ci` for workflow execution and immutable manifests.
- Interrupted publication or registry promotion: [publication recovery](references/publication-recovery.md).
- Native assets: [platform publication](references/platform-publication.md), with `$release-openclaw-mac` for macOS operations.
- Stable postpublish synchronization and the exact-SHA deployment handoff:
  [main closeout](references/stable-main-closeout.md).
- Release retrospective and shared issue ledger (every track, and any handoff
  snapshot): [retrospective](references/retrospective.md).
- Release notes: `$openclaw-changelog-update`, including its separate approved post-release docs-mirror route. Initial release generation keeps its existing format; docs publication does not run automatically during release. Requested announcements: `$release-openclaw-announcement` for Discord, `$release-tweets` for X. Announcements never gate publication and require explicit posting authorization.
- Published artifact verification: `$verify-release`. GHSA operations: `$openclaw-ghsa-maintainer` only with explicit security-workflow authorization.

## Hotfix ledger management

Prefer the [shared hotfix ledger](references/hotfix-ledger-management.md) for
backport discovery, selection, and outcomes, including Tideclaw-owned releases.
Reuse candidates, add discoveries from main/sibling releases, and update each
release's assessments. If access is unavailable, keep local evidence and sync
later. This is recommended bookkeeping, not another release gate.

## Shared release boundaries

FRV must conclude **success** under pinned P's
[checked-in release-tooling policy](../../../docs/reference/full-release-validation/evidence.md#release-tooling-waivers).
Only exact failed live-provider or Telegram leaves may be waived, without
skipping tests or changing C/Q. All other required lanes must succeed: Windows
and macOS Node and other normal CI jobs, install smoke, survivor
lanes, `update-first-hop-compat*`, pack/npm qualification, package integrity,
and Linux/Windows/macOS Gateway checks, including Windows packaged
install/upgrade checks in Release Checks. A cancelled run still blocks. Preserve
first failures and classify each one as below before recovery. Stable
publication requires stable/full evidence, soak, and blocking performance.
Beta-profile evidence cannot authorize stable publication. None of those hard
gates, soak, or performance can be waived. All nine Gateway install/upgrade
combinations across Linux, Windows, and macOS are required for all-group
qualification. Preserve identity, provenance, complete evidence, and existing
publication approvals.

Every failed test gets an explicit lead decision, real release blocker or
flake, recorded in the handoff with its evidence: the same SHA passing
elsewhere or on rerun, no relation to the release delta, a runner or infra
signature, a history of the same case flaking, or a pre-existing product bug
that is not a regression (for example the 2026.9.6 "Assign to…" bug). A real
blocker is a regression in shipped bytes or behavior, or an update/install/
publish defect; fix it on the release branch. Rerun a flake on
the same Release SHA with at most two recorded reruns by default, and file a
fix-in-parallel issue or PR on `main` with the evidence. Never re-cut for a flake.
A deliberate tooling-code waiver requires FRV validation under the new pinned P,
not a publisher override. An unwaived flake that remains red blocks publication.
Main-only failures and infrastructure
failures (runner outages, GitHub ghost jobs, hosted-runner offload) count as
flakes for the release.

Dependency advisories never delay a release. A newly published advisory is
never a reason to re-cut, change tooling, or rerun validation. Record it in the
release evidence and handoff, then file or queue the dependency bump on `main`
as a normal follow-up after publication. Only a known-malware finding stops
publication. Release dependency evidence and release-dispatched CI enforce this.

Main's CI health never gates a release. Validation and publication run from the
release branch plus pinned tooling, so a red `main` is not a reason to wait,
re-cut, or pause. When the release needs a release-tooling fix on `main`
(tooling SHAs must be trusted `main` commits), `main` failures the fix does not
cause must not hold that landing: prove on a clean `main` checkout that the
failure already exists there, record it in the PR body, and merge. During an
active release, an admin merge is allowed for a release-tooling PR in exactly
that situation. Red `main` still gets fixed, in parallel by a separate lane,
never on the release's critical path.

The operating objectives are approximately 20 minutes to seal validation and
publication within an hour, not measured guarantees. Source-only children start
alongside artifact producers; candidate consumers start as soon as the candidate
is ready. Independently sealed green children can be reused for the same exact
target and inputs even when their parent failed, was cancelled, or remains active;
verify their original admitted qualification identity (or historical trusted-main
workflow SHA) and current attempt. The sealed
manifest supplies the SDK evidence digest and npm publication decisions; it
never acknowledges SDK API changes, so supply
`plugin_sdk_api_acknowledgement` whenever the SDK report contains changes. The
publisher accepts only successful FRV and cannot grant a waiver. Explicit
publisher inputs select publication scope; the candidate helper still validates its explicit
SDK acknowledgement when needed.

Use the [owner lifecycle's authority defaults](references/release-owner.md#resolve-authority)
for release-management requests: beta includes validated publication unless
held; stable and extended-stable require publication approval. An explicit
prepare-only request never authorizes publication. An explicit instruction to
publish or complete a named release carries through its validated publication
and verification; do not ask again unless identity, channel, scope, or material
risk changes. Resolve and record the version before changing it; unspecified
versions follow the lifecycle's approval rule. Ship authority for ordinary code
is not release authority.

From openclaw/openclaw, MIT.

More from openclaw/openclaw