[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M698S56E6BMANWYXFTZ8ZY1Q":3,"skill-same:01M698S56E6BMANWYXFTZ8ZY1Q":128},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":44,"ownerHtmlUrl":45,"ownerBlogUrl":44,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M698S56E6BMANWYXFTZ8ZY1Q","release-openclaw-maintainer",null,"Manage one OpenClaw release or orchestrate release owners across beta, stable, and extended-stable: preparation, fix-inclusion tracing, hotfix routing, publication, handoff, and closeout.","openclaw\u002Fopenclaw","openclaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F252820863?v=4","01M698P3FSAZ6B4R928ZF19KPT","01M698PDMDRVH56MV30D253NFP",394302,"MIT","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002FSKILL.md",[],[18,9,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"release openclaw maintainer","release","Publication","tracing","fix","inclusion","owners","preparation","routing","across","closeout","beta","manage","hotfix","orchestrate","handoff","2026-11-10 10:12:30",false,"---\nname: release-openclaw-maintainer\ndescription: \"Manage one OpenClaw release or orchestrate release owners across beta, stable, and extended-stable: preparation, fix-inclusion tracing, hotfix routing, publication, handoff, and closeout.\"\n---\n\n# OpenClaw Release Maintainer\n\nUse for a release operation, not ordinary development or advisory mutation.\nRead `docs\u002Freference\u002FRELEASING.md` for current policy. Load `$release-private`\nwhen available before resolving private credential locators or host topology;\ncredential operations use `$one-password`.\n\n## Choose the role\n\n- **Release owner (default):** “Manage this release” owns one release from\n  preparation through verification, retrospective, and closeout. Start with\n  [the owner lifecycle](references\u002Frelease-owner.md), even for a short prompt.\n- **Release manager \u002F orchestrator:** coordinate several release owners, draft\n  their kickoff or handoff briefs, and route hotfix opportunities. Start with\n  [manager mode](references\u002Frelease-manager.md). This role does not become a\n  second writer of an owner's release branch or publication state.\n\nThe skill owns the general process; the initial prompt carries release-specific\nintent, authority, and state, not a copied runbook. A handoff resumes that intent\nwith current evidence rather than starting another release.\n\n## Choose the operation\n\nRead only the references needed for the selected phase:\n\n- Regular beta\u002Fstable preparation or publication: [regular release](references\u002Fregular-release.md), which routes preparation and phase-specific proof. If the request does not specify stable\u002Ffull, default to beta; beta authorization does not authorize later stable promotion.\n- Fix status, candidate inclusion, first published version, or cumulative upstream-fix counts: [fix-inclusion tracing](references\u002Ffix-inclusion.md).\n- Backport discovery and porting: [candidate inventory and worker brief](references\u002Fbackport-discovery.md). For extended-stable also read [backport preparation](references\u002Fextended-stable-backports.md); SDK\u002Fconfig changes need a visible maintenance-risk warning and maintainer decision.\n- Extended-stable `.33+` Gateway publication: [extended-stable publication](references\u002Fextended-stable-publish.md). Use the shared publisher with extended-stable inputs; its non-Latest GitHub Release carries evidence without native-app or ClawHub publication.\n- Validation selection or failed proof: [validation and confidence](references\u002Fvalidation.md), with `$release-openclaw-ci` for workflow execution and immutable manifests.\n- Interrupted publication or registry promotion: [publication recovery](references\u002Fpublication-recovery.md).\n- Native assets: [platform publication](references\u002Fplatform-publication.md), with `$release-openclaw-mac` for macOS operations.\n- Stable postpublish synchronization and the exact-SHA deployment handoff:\n  [main closeout](references\u002Fstable-main-closeout.md).\n- Release retrospective and shared issue ledger (every track, and any handoff\n  snapshot): [retrospective](references\u002Fretrospective.md).\n- 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.\n- Published artifact verification: `$verify-release`. GHSA operations: `$openclaw-ghsa-maintainer` only with explicit security-workflow authorization.\n\n## Backports and new fixes\n\nFor every release track, apply approved changes already on `main` directly to\nthe canonical release branch, one commit at a time in dependency order with\n`git cherry-pick -x`. Keep each backport separate, including the initial set;\nnever open individual backport PRs or a combined staging\u002Fmega PR for that work.\nRecord source and destination SHAs, adaptations, and proof in the release ledger.\n\nFor a new fix not yet on `main`, prefer an individual PR to `main`, then direct\nbackport after it merges. When urgency requires a release-first fix, commit it\ndirectly to the release branch and track an individual forward-port PR to\n`main` after publication, with an owner in the handoff. Do not lose the fix at\ncloseout. This applies to product, CI, and release-tooling repairs; independently\ntrusted publishing tooling P must still come from `main`.\n\nCI can be repaired after backports are on the release branch; it is not a\nreason to open a backport PR or stage the initial set behind one. Backport an\nexisting main fix directly; otherwise use the new-fix route above. Run focused\nproof and repair branch CI before freezing and qualifying the final candidate.\nRequired release validation, intake approval, security disclosure, and exact-SHA\nevidence remain unchanged; direct backports do not authorize publication.\n\n## Hotfix ledger management\n\nPrefer the [shared hotfix ledger](references\u002Fhotfix-ledger-management.md) for\nbackport discovery, selection, and outcomes, including Tideclaw-owned releases.\nReuse candidates, add discoveries from main\u002Fsibling releases, and update each\nrelease's assessments. If access is unavailable, keep local evidence and sync\nlater. This is recommended bookkeeping, not another release gate.\n\n## Shared release boundaries\n\nFRV must conclude **success** under pinned P's\n[checked-in release-tooling policy](..\u002F..\u002F..\u002Fdocs\u002Freference\u002Ffull-release-validation\u002Fevidence.md#release-tooling-waivers).\nOnly exact failed live-provider or Telegram leaves may be waived, without\nskipping tests or changing C\u002FQ. All other required lanes must succeed: Windows\nand macOS Node and other normal CI jobs, install smoke, survivor\nlanes, `update-first-hop-compat*`, pack\u002Fnpm qualification, package integrity,\nand Linux\u002FWindows\u002FmacOS Gateway checks, including Windows packaged\ninstall\u002Fupgrade checks in Release Checks. A cancelled run still blocks. Preserve\nfirst failures and classify each one as below before recovery. Stable\npublication requires stable\u002Ffull evidence, soak, and blocking performance.\nBeta-profile evidence cannot authorize stable publication. None of those hard\ngates, soak, or performance can be waived. All nine Gateway install\u002Fupgrade\ncombinations across Linux, Windows, and macOS are required for all-group\nqualification. Preserve identity, provenance, complete evidence, and existing\npublication approvals.\n\nEvery failed test gets an explicit lead decision, real release blocker or\nflake, recorded in the handoff with its evidence: the same SHA passing\nelsewhere or on rerun, no relation to the release delta, a runner or infra\nsignature, a history of the same case flaking, or a pre-existing product bug\nthat is not a regression (for example the 2026.9.6 \"Assign to…\" bug). A real\nblocker is a regression in shipped bytes or behavior, or an update\u002Finstall\u002F\npublish defect; fix it on the release branch. Rerun a flake on\nthe same Release SHA with at most two recorded reruns by default, and file a\nfix-in-parallel issue or PR on `main` with the evidence. Never re-cut for a flake.\nA deliberate tooling-code waiver requires FRV validation under the new pinned P,\nnot a publisher override. An unwaived flake that remains red blocks publication.\nMain-only failures and infrastructure\nfailures (runner outages, GitHub ghost jobs, hosted-runner offload) count as\nflakes for the release.\n\nDependency advisories never delay a release. A newly published advisory is\nnever a reason to re-cut, change tooling, or rerun validation. Record it in the\nrelease evidence and handoff, then file or queue the dependency bump on `main`\nas a normal follow-up after publication. Only a known-malware finding stops\npublication. Release dependency evidence and release-dispatched CI enforce this.\n\nMain's CI health never gates a release. Validation and publication run from the\nrelease branch plus pinned tooling, so a red `main` is not a reason to wait,\nre-cut, or pause. When the release needs a release-tooling fix on `main`\n(tooling SHAs must be trusted `main` commits), `main` failures the fix does not\ncause must not hold that landing: prove on a clean `main` checkout that the\nfailure already exists there, record it in the PR body, and merge. During an\nactive release, an admin merge is allowed for a release-tooling PR in exactly\nthat situation. Red `main` still gets fixed, in parallel by a separate lane,\nnever on the release's critical path.\n\nFollow the [FRV wall-time loop](..\u002Frelease-openclaw-ci\u002FSKILL.md#keep-frv-off-the-idle-path):\nstart remote validation promptly, repair failures as diagnostics drain, and\nminimize downtime between cycles. Include every known non-flake fix affecting\nthe next run rather than knowingly carrying failures forward; overlap useful\nlocal checks with remote validation. This guides scheduling, not new gates.\n\nThe operating objectives are approximately 20 minutes to seal validation and\npublication within an hour, not measured guarantees. Source-only children start\nalongside artifact producers; candidate consumers start as soon as the candidate\nis ready. Independently sealed green children can be reused for the same exact\ntarget and inputs even when their parent failed, was cancelled, or remains active;\nverify their original admitted qualification identity (or historical trusted-main\nworkflow SHA) and current attempt. The sealed\nmanifest supplies the SDK evidence digest and npm publication decisions; it\nnever acknowledges SDK API changes, so supply\n`plugin_sdk_api_acknowledgement` whenever the SDK report contains changes. The\npublisher accepts only successful FRV and cannot grant a waiver. Explicit\npublisher inputs select publication scope; the candidate helper still validates its explicit\nSDK acknowledgement when needed.\n\nUse the [owner lifecycle's authority defaults](references\u002Frelease-owner.md#resolve-authority)\nfor release-management requests: beta includes validated publication unless\nheld; stable and extended-stable require publication approval. An explicit\nprepare-only request never authorizes publication. An explicit instruction to\npublish or complete a named release carries through its validated publication\nand verification; do not ask again unless identity, channel, scope, or material\nrisk changes. Resolve and record the version before changing it; unspecified\nversions follow the lifecycle's approval rule. Ship authority for ordinary code\nis not release authority.\n\nAn operator's explicit approval to do whatever is needed to prepare a named\nrelease is standing authority for the necessary preparation decisions and\nrepairs. Carry it through candidate and tooling fixes, upgrade\u002Fmigration design,\nreviewed test or security-inventory alignments, isolated proof, commits, pushes,\nand validation recovery. Record the decision, its evidence, and the selected\nsupport contract; do not ask again merely because an already-approved class of\nwork reaches an implementation or verification step. Continue independent work\nwhile resolving a blocker. This authority does not permit hiding defects,\nlowering a gate to manufacture success, destructive changes to operator state,\nunrelated work, or publication. A prepare-only request still requires a separate\npublication instruction before releasing artifacts or a bridge version.\n\nKeep one compact state record using\n[the handoff template](references\u002Frelease-handoff-template.md): effective goal,\nversion\u002Ftag\u002Fbranch, cut\u002FCode\u002FRelease SHAs, C\u002FQ\u002FP identities, active parent run and attempt,\nsuccessful child artifacts, approved changes, phase and next action. Latest\noperator steering replaces superseded scope. Completed evidence stays complete\nuntil a named change invalidates it.\n\nFor regular releases, prepare complete notes before freezing **Code SHA** when\npossible. If those notes are final, **Code SHA and Release SHA are the same\ncommit**: one successful fresh full qualification can supply both roles and\ntheir exact publication bytes. Do not create another commit or run solely to\nseparate the labels. If notes change after qualification, a descendant whose\ncomplete delta includes `CHANGELOG\u002F\u003Cversion>.md` (exact beta version or stable\nbase) and only that entry, its\nmatching record, and root index may use `split-changelog-release-v1`\nto reuse product proof while qualifying new publication bytes. Any other\nsource delta, rename, or deletion returns to the Code SHA loop. Historical\nroot-only receipts retain `changelog-only-release-v1`.\nNew test qualification freezes **Q=C**: the candidate's test workflow closure\nbelongs to the candidate. Keep independently trusted **P** (admission, aggregate\ndecision, verifier, and publisher) separate. A Q harness repair requires a new C\u002FQ and newly bound\nevidence; P-only or infrastructure repairs can preserve the candidate. Missing\nqualification contracts need a deliberate backport, never future-main fallback.\n\nOnce a candidate is cut, its base is the operator's decision. Never re-cut\n(re-base the candidate on newer `main`) unless Peter explicitly asks for it in\nthat release. Without asking, cherry-pick already-merged `main` commits onto\nthe release branch only to fix a confirmed release blocker: a required lane\nfailing deterministically on the frozen candidate, or an update\u002Finstall\u002F\npublish-bytes defect. Name each cherry-pick in the handoff record. Not allowed:\nopportunistic backports, feature reverts, or a new base taken to \"pick up\" a\nfix that cherry-picks cleanly enough with a small conflict resolution.\nExplicit operator-approved additions follow the\n[owner intake procedure](references\u002Frelease-owner.md#prepare-and-admit-hotfixes):\nrecord the changed scope and requalify the new candidate, never silently reuse\ninvalidated proof. A manager's opportunity notification is not that approval.\n\nRelease process improvements made during a release land on both branches.\nWorkflow, release-script, release-test, `RELEASING.md`, and release-skill changes\nnormally merge to `main` first, then get cherry-picked (`-x`) directly onto the\ncanonical release branch for the next candidate or patch, without a backport PR.\nUrgent release-first repairs follow [the new-fix route](#backports-and-new-fixes).\nA qualification repair needed for this release\nmust land before freezing a new C\u002FQ; never silently swap the harness for an\nalready qualified candidate. Where `main`-only CI infrastructure is missing on the branch,\nkeep the branch's expression form and port only the logic. Product code on the\nrelease branch stays blocker-only per the rule above.\n\nResolve every repair PR opened for the release before the final report. The\nretrospective PR described below is the required open closeout deliverable, not\nan unresolved repair. List every PR created during the release (`gh pr list --author\n@me --state open` plus any PR bound to the session) and land or explicitly close\neach repair PR with a reason; confirm its fix is on `main` and, when it is release\ntooling, on the release branch. Also remove the release's temporary worktrees,\nabandoned local cut branches, and stale `scripts\u002Fpr` worktrees. Then write the\n[retrospective](references\u002Fretrospective.md) and open its `openclaw\u002Ftideclaw`\nPR with the issue-ledger update; keep a findings notes file from the start of the\nrelease so it can be written from evidence.\n\nPublished versions and final tags are immutable. Reuse successful exact-source\nartifacts; do not rebuild or republish as an implicit retry. The active release\nis the work queue: no opportunistic moving-main fixes or backports. Classify\nfailures, repair their owner, retry the affected surface, then reassess rather\nthan repeating the full release.\n\nRequired publication proofs and enforced environment approvals remain required.\nA passing sibling cannot replace missing required evidence. npm + ClawHub is the\npriority path. macOS, Windows, Linux, and Android native publication runs in\nparallel and never gates npm\u002FClawHub, GitHub release finalization, or main closeout.\nSelected Windows Node, Linux\u002FWindows\u002FmacOS Gateway, and native-app CI failures\nblock release validation. Platform publishers retain their own artifact\nand updater contracts; report pending platforms and proof gaps accurately.\n","# OpenClaw Release Maintainer\n\nUse for a release operation, not ordinary development or advisory mutation.\nRead `docs\u002Freference\u002FRELEASING.md` for current policy. Load `$release-private`\nwhen available before resolving private credential locators or host topology;\ncredential operations use `$one-password`.\n\n## Choose the role\n\n- **Release owner (default):** “Manage this release” owns one release from\n  preparation through verification, retrospective, and closeout. Start with\n  [the owner lifecycle](references\u002Frelease-owner.md), even for a short prompt.\n- **Release manager \u002F orchestrator:** coordinate several release owners, draft\n  their kickoff or handoff briefs, and route hotfix opportunities. Start with\n  [manager mode](references\u002Frelease-manager.md). This role does not become a\n  second writer of an owner's release branch or publication state.\n\nThe skill owns the general process; the initial prompt carries release-specific\nintent, authority, and state, not a copied runbook. A handoff resumes that intent\nwith current evidence rather than starting another release.\n\n## Choose the operation\n\nRead only the references needed for the selected phase:\n\n- Regular beta\u002Fstable preparation or publication: [regular release](references\u002Fregular-release.md), which routes preparation and phase-specific proof. If the request does not specify stable\u002Ffull, default to beta; beta authorization does not authorize later stable promotion.\n- Fix status, candidate inclusion, first published version, or cumulative upstream-fix counts: [fix-inclusion tracing](references\u002Ffix-inclusion.md).\n- Backport discovery and porting: [candidate inventory and worker brief](references\u002Fbackport-discovery.md). For extended-stable also read [backport preparation](references\u002Fextended-stable-backports.md); SDK\u002Fconfig changes need a visible maintenance-risk warning and maintainer decision.\n- Extended-stable `.33+` Gateway publication: [extended-stable publication](references\u002Fextended-stable-publish.md). Use the shared publisher with extended-stable inputs; its non-Latest GitHub Release carries evidence without native-app or ClawHub publication.\n- Validation selection or failed proof: [validation and confidence](references\u002Fvalidation.md), with `$release-openclaw-ci` for workflow execution and immutable manifests.\n- Interrupted publication or registry promotion: [publication recovery](references\u002Fpublication-recovery.md).\n- Native assets: [platform publication](references\u002Fplatform-publication.md), with `$release-openclaw-mac` for macOS operations.\n- Stable postpublish synchronization and the exact-SHA deployment handoff:\n  [main closeout](references\u002Fstable-main-closeout.md).\n- Release retrospective and shared issue ledger (every track, and any handoff\n  snapshot): [retrospective](references\u002Fretrospective.md).\n- 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.\n- Published artifact verification: `$verify-release`. GHSA operations: `$openclaw-ghsa-maintainer` only with explicit security-workflow authorization.\n\n## Backports and new fixes\n\nFor every release track, apply approved changes already on `main` directly to\nthe canonical release branch, one commit at a time in dependency order with\n`git cherry-pick -x`. Keep each backport separate, including the initial set;\nnever open individual backport PRs or a combined staging\u002Fmega PR for that work.\nRecord source and destination SHAs, adaptations, and proof in the release ledger.\n\nFor a new fix not yet on `main`, prefer an individual PR to `main`, then direct\nbackport after it merges. When urgency requires a release-first fix, commit it\ndirectly to the release branch and track an individual forward-port PR to\n`main` after publication, with an owner in the handoff. Do not lose the fix at\ncloseout. This applies to product, CI, and release-tooling repairs; independently\ntrusted publishing tooling P must still come from `main`.\n\nCI can be repaired after backports are on the release branch; it is not a\nreason to open a backport PR or stage the initial set behind one. Backport an\nexisting main fix directly; otherwise use the new-fix route above. Run focused\nproof and repair branch CI before freezing and qualifying the final candidate.\nRequired release validation, intake approval, security disclosure, and exact-SHA\nevidence remain unchanged; direct backports do not authorize publication.\n\n## Hotfix ledger management\n\nPrefer the [shared hotfix ledger](references\u002Fhotfix-ledger-management.md) for\nbackport discovery, selection, and outcomes, including Tideclaw-owned releases.\nReuse candidates, add discoveries from main\u002Fsibling releases, and update each\nrelease's assessments. If access is unavailable, keep local evidence and sync\nlater. This is recommended bookkeeping, not another release gate.\n\n## Shared release boundaries\n\nFRV must conclude **success** under pinned P's\n[checked-in release-tooling policy](..\u002F..\u002F..\u002Fdocs\u002Freference\u002Ffull-release-validation\u002Fevidence.md#release-tooling-waivers).\nOnly exact failed live-provider or Telegram leaves may be waived, without\nskipping tests or changing C\u002FQ. All other required lanes must succeed: Windows\nand macOS Node and other normal CI jobs, install smoke, survivor\nlanes, `update-first-hop-compat*`, pack\u002Fnpm qualification, package integrity,\nand Linux\u002FWindows\u002FmacOS Gateway checks, including Windows packaged\ninstall\u002Fupgrade checks in Release Checks. A cancelled run still blocks. Preserve\nfirst failures and classify each one as below before recovery. Stable\npublication requires stable\u002Ffull evidence, soak, and blocking performance.\nBeta-profile evidence cannot authorize stable publication. None of those hard\ngates, soak, or performance can be waived. All nine Gateway install\u002Fupgrade\ncombinations across Linux, Windows, and macOS are required for all-group\nqualification. Preserve identity, provenance, complete evidence, and existing\npublication approvals.\n\nEvery failed test gets an explicit lead decision, real release blocker or\nflake, recorded in the handoff with its evidence: the same SHA passing\nelsewhere or on rerun, no relation to the release delta, a runner or infra\nsignature, a history of the same case flaking, or a pre-existing product bug\nthat is not a regression (for example the 2026.9.6 \"Assign to…\" bug). A real\nblocker is a regression in shipped bytes or behavior, or an update\u002Finstall\u002F\npublish defect; fix it on the release branch. Rerun a flake on\nthe same Release SHA with at most two recorded reruns by default, and file a\nfix-in-parallel issue or PR on `main` with the evidence. Never re-cut for a flake.\nA deliberate tooling-code waiver requires FRV validation under the new pinned P,\nnot a publisher override. An unwaived flake that remains red blocks publication.\nMain-only failures and infrastructure\nfailures (runner outages, GitHub ghost jobs, hosted-runner offload) count as\nflakes for the release.\n\nDependency advisories never delay a release. A newly published advisory is\nnever a reason to re-cut, change tooling, or rerun validation. Record it in the\nrelease evidence and handoff, then file or queue the dependency bump on `main`\nas a normal follow-up after publication. Only a known-malware finding stops\npublication. Release dependency evidence and release-dispatched CI enforce this.\n\nMain's CI health never gates a release. Validation and publication run from the\nrelease branch plus pinned tooling, so a red `main` is not a reason to wait,\nre-cut, or pause. When the release needs a release-tooling fix on `main`\n(tooling SHAs must be trusted `main` commits), `main` failures the fix does not\ncause must not hold that landing: prove on a clean `main` checkout that the\nfailure already exists there, record it in the PR body, and merge. During an\nactive release, an admin merge is allowed for a release-tooling PR in exactly\nthat situation. Red `main` still gets fixed, in parallel by a separate lane,\nnever on the release's critical path.\n\nFollow the [FRV wall-time loop](..\u002Frelease-openclaw-ci\u002FSKILL.md#keep-frv-off-the-idle-path):\nstart remote validation promptly, repair failures as diagnostics drain, and\nminimize downtime between cycles. Include every known non-flake fix affecting\nthe next run rather than knowingly carrying failures forward; overlap useful\nlocal checks with remote validation. This guides scheduling, not new gates.\n\nThe operating objectives are approximately 20 minutes to seal validation and\npublication within an hour, not measured guarantees. Source-only children start\nalongside artifact producers; candidate consumers start as soon as the candidate\nis ready. Independently sealed green children can be reused for the same exact\ntarget and inputs even when their parent failed, was cancelled, or remains active;\nverify their original admitted qualification identity (or historical trusted-main\nworkflow SHA) and current attempt. The sealed\nmanifest supplies the SDK evidence digest and npm publication decisions; it\nnever acknowledges SDK API changes, so supply\n`plugin_sdk_api_acknowledgement` whenever the SDK report contains changes. The\npublisher accepts only successful FRV and cannot grant a waiver. Explicit\npublisher inputs select publication scope; the candidate helper still validates its explicit\nSDK acknowledgement when needed.\n\nUse the [owner lifecycle's authority defaults](references\u002Frelease-owner.md#resolve-authority)\nfor release-management requests: beta includes validated publication unless\nheld; stable and extended-stable require publication approval. An explicit\nprepare-only request never authorizes publication. An explicit instruction to\npublish or complete a named release carries through its validated publication\nand verification; do not ask again unless identity, channel, scope, or material\nrisk changes. Resolve and record the version before changing it; unspecified\nversions follow the lifecycle's approval rule. Ship authority for ordinary code\nis not release authority.\n\nAn operator's explicit approval to do whatever is needed to prepare a named\nrelease is standing authority for the necessary preparation decisions and\nrepairs. Carry it through candidate and tooling fixes, upgrade\u002Fmigration design,\nreviewed test or security-inventory alignments, isolated proof, commits, pushes,\nand validation recovery. Record the decision, its evidence, and the selected\nsupport contract; do not ask again merely because an already-approved class of\nwork reaches an implementation or verification step. Continue independent work\nwhile resolving a blocker. This authority does not permit hiding defects,\nlowering a gate to manufacture success, destructive changes to operator state,\nunrelated work, or publication. A prepare-only request still requires a separate\npublication instruction before releasing artifacts or a bridge version.\n\nKeep one compact state record using\n[the handoff template](references\u002Frelease-handoff-template.md): effective goal,\nversion\u002Ftag\u002Fbranch, cut\u002FCode\u002FRelease SHAs, C\u002FQ\u002FP identities, active parent run and attempt,\nsuccessful child artifacts, approved changes, phase and next action. Latest\noperator steering replaces superseded scope. Completed evidence stays complete\nuntil a named change invalidates it.\n\nFor regular releases, prepare complete notes before freezing **Code SHA** when\npossible. If those notes are final, **Code SHA and Release SHA are the same\ncommit**: one successful fresh full qualification can supply both roles and\ntheir exact publication bytes. Do not create another commit or run solely to\nseparate the labels. If notes change after qualification, a descendant whose\ncomplete delta includes `CHANGELOG\u002F\u003Cversion>.md` (exact beta version or stable\nbase) and only that entry, its\nmatching record, and root index may use `split-changelog-release-v1`\nto reuse product proof while qualifying new publication bytes. Any other\nsource delta, rename, or deletion returns to the Code SHA loop. Historical\nroot-only receipts retain `changelog-only-release-v1`.\nNew test qualification freezes **Q=C**: the candidate's test workflow closure\nbelongs to the candidate. Keep independently trusted **P** (admission, aggregate\ndecision, verifier, and publisher) separate. A Q harness repair requires a new C\u002FQ and newly bound\nevidence; P-only or infrastructure repairs can preserve the candidate. Missing\nqualification contracts need a deliberate backport, never future-main fallback.\n\nOnce a candidate is cut, its base is the operator's decision. Never re-cut\n(re-base the candidate on newer `main`) unless Peter explicitly asks for it in\nthat release. Without asking, cherry-pick already-merged `main` commits onto\nthe release branch only to fix a confirmed release blocker: a required lane\nfailing deterministically on the frozen candidate, or an update\u002Finstall\u002F\npublish-bytes defect. Name each cherry-pick in the handoff record. Not allowed:\nopportunistic backports, feature reverts, or a new base taken to \"pick up\" a\nfix that cherry-picks cleanly enough with a small conflict resolution.\nExplicit operator-approved additions follow the\n[owner intake procedure](references\u002Frelease-owner.md#prepare-and-admit-hotfixes):\nrecord the changed scope and requalify the new candidate, never silently reuse\ninvalidated proof. A manager's opportunity notification is not that approval.\n\nRelease process improvements made during a release land on both branches.\nWorkflow, release-script, release-test, `RELEASING.md`, and release-skill changes\nnormally merge to `main` first, then get cherry-picked (`-x`) directly onto the\ncanonical release branch for the next candidate or patch, without a backport PR.\nUrgent release-first repairs follow [the new-fix route](#backports-and-new-fixes).\nA qualification repair needed for this release\nmust land before freezing a new C\u002FQ; never silently swap the harness for an\nalready qualified candidate. Where `main`-only CI infrastructure is missing on the branch,\nkeep the branch's expression form and port only the logic. Product code on the\nrelease branch stays blocker-only per the rule above.\n\nResolve every repair PR opened for the release before the final report. The\nretrospective PR described below is the required open closeout deliverable, not\nan unresolved repair. List every PR created during the release (`gh pr list --author\n@me --state open` plus any PR bound to the session) and land or explicitly close\neach repair PR with a reason; confirm its fix is on `main` and, when it is release\ntooling, on the release branch. Also remove the release's temporary worktrees,\nabandoned local cut branches, and stale `scripts\u002Fpr` worktrees. Then write the\n[retrospective](references\u002Fretrospective.md) and open its `openclaw\u002Ftideclaw`\nPR with the issue-ledger update; keep a findings notes file from the start of the\nrelease so it can be written from evidence.\n\nPublished versions and final tags are immutable. Reuse successful exact-source\nartifacts; do not rebuild or republish as an implicit retry. The active release\nis the work queue: no opportunistic moving-main fixes or backports. Classify\nfailures, repair their owner, retry the affected surface, then reassess rather\nthan repeating the full release.\n\nRequired publication proofs and enforced environment approvals remain required.\nA passing sibling cannot replace missing required evidence. npm + ClawHub is the\npriority path. macOS, Windows, Linux, and Android native publication runs in\nparallel and never gates npm\u002FClawHub, GitHub release finalization, or main closeout.\nSelected Windows Node, Linux\u002FWindows\u002FmacOS Gateway, and native-app CI failures\nblock release validation. Platform publishers retain their own artifact\nand updater contracts; report pending platforms and proof gaps accurately.\n",{"name":5,"description":7},"main","c37e3897be60e2db9db3aefba9cee92bcb193b51",".agents\u002Fskills\u002Frelease-openclaw-maintainer",82862,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw","https:\u002F\u002Fopenclaw.ai","https:\u002F\u002Fgithub.com\u002Fopenclaw","Your personal, open source AI assistant.","2026-11-11 08:46:30",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add openclaw\u002Fopenclaw --skill release-openclaw-maintainer",{"tool":54,"command":55},"bunx","bunx skills add openclaw\u002Fopenclaw --skill release-openclaw-maintainer",{"tool":57,"command":58},"pnpm","pnpm dlx skills add openclaw\u002Fopenclaw --skill release-openclaw-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002FSKILL.md",true,[62,68,72,76,80,84,88,92,96,100,104,108,112,116,120,124],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Fbackport-discovery.md","REFERENCE","参考文档",14295,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fbackport-discovery.md",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fextended-stable-backports.md",21036,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fextended-stable-backports.md",{"path":73,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fextended-stable-publish.md",11287,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fextended-stable-publish.md",{"path":77,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Ffirst-package.md",4767,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Ffirst-package.md",{"path":81,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Ffix-inclusion.md",2060,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Ffix-inclusion.md",{"path":85,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fhotfix-ledger-management.md",11375,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fhotfix-ledger-management.md",{"path":89,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fplatform-publication.md",14260,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fplatform-publication.md",{"path":93,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fpreparation.md",10159,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fpreparation.md",{"path":97,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fpublication-recovery.md",26290,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fpublication-recovery.md",{"path":101,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fregular-release.md",30924,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fregular-release.md",{"path":105,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Frelease-handoff-template.md",10320,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Frelease-handoff-template.md",{"path":109,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Frelease-manager.md",9552,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Frelease-manager.md",{"path":113,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Frelease-owner.md",13085,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Frelease-owner.md",{"path":117,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fretrospective.md",4138,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fretrospective.md",{"path":121,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Fstable-main-closeout.md",10168,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fstable-main-closeout.md",{"path":125,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":126,"sourceHtmlUrl":127},"references\u002Fvalidation.md",13985,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-openclaw-maintainer\u002Freferences\u002Fvalidation.md",[129,135,158,176,198,221],{"skillNo":130,"name":131,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":34},"01M698VP84FNM6G9MR1HPX7MF7","lobster","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Flobster\u002FSKILL.md",[],[131],{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":34},"01M698YY8QGQ7S8TJNKJG6VTPH","xurl","xurl CLI for authenticated X posts, replies, reads\u002Fsearch, DMs, media upload, followers, auth status, or raw v2 API calls.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fxurl\u002FSKILL.md",[],[137,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157],"for","api","calls","replies","posts","upload","tap","install","brew","node","Media","search","npm","status","auth","cli",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":34},"01M698YWT1CJ0WK88WB909R9RT","weather","Current weather and forecasts with web_fetch, falling back to wttr.in curl for locations, rain, temperature, travel planning.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[160,165,166,149,167,150,168,169,170,171,172,173,142,174,175],"travel planning","travel","fetch","curl","https","help","planning","web","back","temperature","with",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":187,"publishedAt":34},"01M698YV2Q0R0JJKAWGFS21K0N","visualize","Create inline visuals for code and explanations, or author persistent OpenClaw dashboard widgets with show_widget.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fvisualize\u002FSKILL.md",[182],{"categoryNo":183,"categoryName":184,"taxonomyType":185,"taxonomyTypeDesc":186},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[178,188,189,190,191,142,175,192,193,194,195,196,9,197],"widgets","openclaw dashboard","author","inline","show","code","create","visuals","dashboard","widget",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":212,"publishedAt":34},"01M698YS2TRJH9ENG28HD9CD87","trello","Manage Trello boards, lists, and cards via the Trello REST API.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftrello\u002FSKILL.md",[204,209],{"categoryNo":205,"categoryName":206,"taxonomyType":207,"taxonomyTypeDesc":208},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":210,"categoryName":211,"taxonomyType":185,"taxonomyTypeDesc":186},"01JBSEEDCAT000000000000030","开发工程师",[200,169,213,30,214,215,216,217,149,150,218,168,143,219,220],"cloud","via","rest api","token","atlassian","jq","REST","developer",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":227,"publishedAt":34},"01M698YQ9Q3M4W78EWV2KSCSVW","tmux","Control tmux sessions\u002Fpanes for interactive CLIs: list, capture output, send keys, paste text, monitor prompts.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftmux\u002FSKILL.md",[],[223,149,228,229,142,230,231,232,233,234,235,236,150,237,238,239,240,241,242],"send","darwin","keys","paste","output","control","prompts","interactive","list","capture","panes","text","monitor","sessions","linux"]