[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M698QNCC599ZXAP9SA88FWHB":3,"skill-same:01M698QNCC599ZXAP9SA88FWHB":62},{"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":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":38,"ownerHtmlUrl":39,"ownerBlogUrl":38,"ownerDescription":40,"updatedAt":41,"install":42,"resources":55},"01M698QNCC599ZXAP9SA88FWHB","openclaw-changelog-update",null,"Regenerate OpenClaw release changelog sections from git history before beta, stable, or extended-stable releases.","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\u002Fopenclaw-changelog-update\u002FSKILL.md",[],[18,9,19,20,21,22,23,24,25,26,27],"openclaw changelog update","changelog update","changelog","update","history","beta","release changelog","releases","release","git","2026-11-10 10:12:30",false,"---\nname: openclaw-changelog-update\ndescription: Regenerate OpenClaw release changelog sections from git history before beta, stable, or extended-stable releases.\n---\n\n# OpenClaw Changelog Update\n\nUse this for changelog rewrites and GitHub release-note source text. For regular\nbeta\u002Fstable, prepare complete notes before final-source qualification when\npossible; Code SHA may then also be Release SHA. Editorial work may overlap\nCode validation. Do not rerun it per validation-recovery backport; when backports\nreplace the Code SHA, rerun it once after the final Code SHA is green, as a\ngenuine CHANGELOG-only descendant under the existing product-evidence reuse\npolicy ([timing](..\u002Frelease-openclaw-maintainer\u002Freferences\u002Fpreparation.md#changelog-and-release-notes)). For\nextended-stable, run it before final exact-head validation and tagging. Do not\nrerun it for tooling retries, resumed publication, or promotion.\nUse it with `release-openclaw-maintainer`; this skill owns changelog content,\nordering, grouping, and attribution discipline.\n\n## Goal\n\nRebuild the target `CHANGELOG\u002F\u003Cversion>.md` release section from a complete, generated\nhistory manifest, not stale draft notes. Produce grouped user-facing release\nnotes sorted by user interest while preserving every relevant issue\u002FPR ref and\nevery verified human `Thanks @...` attribution.\n\n`CHANGELOG.md` is the generated release index. The shared owner\n`scripts\u002Flib\u002Frelease-changelog.mjs` resolves release sections and contribution\nrecords from a working tree or a pinned Git ref, including historical refs\nthat still contain a monolith. Use `node scripts\u002Frelease-changelog.mjs read\n--version \u003Cversion> [--ref \u003Csha-or-tag>]` for a section, or add `--record` for\nits contribution record. A missing split artifact must not fall back to the\nroot index. Historical releases without records gain no invented provenance.\nGenerated `CHANGELOG\u002F**` files retain exact migrated or mirrored bytes and are\nexcluded from generic formatting, like the root changelog. Validate them through\ntheir owner with `pnpm changelog:check`.\n\nCurrent writes use the split layout. To save a complete initial section, use\n`node scripts\u002Frelease-changelog.mjs write --version \u003Cversion> --file \u003Csection.md>`;\nit updates the release entry, matching `CHANGELOG\u002Frecords\u002F\u003Cversion>.md` when\npresent, and index together. Initial generation retains the section format\nbelow. Published docs mirrors follow the separate post-release route at the end\nof this skill; initial generation must never overwrite them.\n\n## Inputs\n\n- Target version: exact `YYYY.M.PATCH-beta.N` for a beta delta; `YYYY.M.PATCH`\n  for cumulative stable notes. Beta entries and records are separate frozen\n  artifacts, never copies of the stable-base section.\n- Beta base tag: capture the version currently selected by public npm\n  `openclaw@beta` before publication, not the last GitHub prerelease or the\n  highest beta-suffixed version. The selector may name a stable version also\n  selected by `latest`. Omit `--base` (or use `--base npm-beta`) with an exact\n  beta version to resolve it once; preserve the resolved tag from the generated\n  manifest and reuse that explicit `--base` for edits, verification and recovery.\n  If npm already selects the candidate or a newer version, generation refuses\n  to guess historical selector state; supply the previously captured tag. When\n  that tag is not an ancestor (for example a stable closeout forward-port), the\n  verifier uses its reachable merge base and subtracts the captured shipped\n  tag's cumulative PR record through `--shipped-ref` semantics. The manifest and\n  record retain both boundaries; replay with the captured tag to resolve the\n  same range, never select an older GitHub beta instead.\n- Stable base tag: last reachable shipped stable release tag. It must be an ancestor of\n  the target; a newer but divergent tag is not a valid history boundary. Use\n  an explicit shipped\u002Fmain-closeout SHA only when it is also reachable from the\n  target.\n- Target ref: the exact product-complete history being documented. Its\n  contribution-record target must be an ancestor of the final release target;\n  it need not name a not-yet-created changelog commit. Include any later fixes\n  before finalizing notes. Final notes may be committed before qualification,\n  or afterward as a CHANGELOG-only descendant of a green Code SHA.\n- Canonical main ref: current `origin\u002Fmain`, fetched before verification. Release\n  notes cite the original merged main PR when the same work is carried by a\n  backport. A release-branch PR is used only while no forward-port exists on\n  current main.\n\n## Workflow\n\n1. Confirm the release branch and exact history target:\n   - `git fetch --tags origin`\n   - confirm clean `git status -sb`\n   - record `git rev-parse HEAD` as the history target\n   - record the Full Release Validation run id and attempt when qualification already exists\n   - finish pending product\u002Fversion\u002Fbackport changes before freezing final source; refresh the inventory for actual changes\n2. Audit history, including direct commits:\n   - `git log --topo-order --date=iso-strict --pretty=format:'%h%x09%ad%x09%s' \u003Cbase-tag>..\u003Ctarget-ref>`\n   - `git log --topo-order --grep='(#' --date=short --pretty=format:'%h%x09%ad%x09%s' \u003Cbase-tag>..\u003Ctarget-ref>`\n   - Include every commit reachable from the target but not the base, including merged side branches. Resolve PR associations before deduplicating and subtracting shipped records; retain the existing revert exclusions.\n   - also inspect `--since='24 hours ago'` when main moved during the release.\n3. Generate the complete contribution record and editorial manifest before\n   writing grouped prose:\n\n   ```bash\n   node --import tsx .agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs \\\n     --base \u003Cbase-tag> \\\n     --target \u003Ctarget-ref> \\\n     --release-branch \u003Ccanonical-release-branch> \\\n     --main-ref origin\u002Fmain \\\n     --version \u003CYYYY.M.PATCH> \\\n     --manifest \u002Ftmp\u002Fopenclaw-release-\u003CYYYY.M.PATCH>.json \\\n     --write-ledger\n   ```\n\n   For beta generation, use `--version YYYY.M.PATCH-beta.N` and omit `--base`\n   on the first inventory run. Start an exact-version section with Highlights,\n   Changes and Fixes using the shared writer; generate the delta manifest, then\n   write prose for that range only. Subsequent runs use the captured npm baseline\n   tag explicitly (not only a divergent range's merge-base SHA). Do not query npm again after publication or overwrite the\n   cumulative stable entry. Regenerate cumulative stable notes at stable prep.\n\n   Add repeatable `--release-provenance '\u003C40sha> -> #PR[, #PR]'` inputs when\n   release commits cannot carry provenance metadata. These use the same exact\n   marker grammar and source validation as commit-body markers. A merged\n   release-branch original is valid only while no corresponding current-main\n   forward-port exists; its GitHub merge commit pins the original source.\n\n   The verifier automatically reuses public GitHub GraphQL responses from an\n   exact base\u002Ftarget SHA snapshot under the worktree's git metadata. Iterative\n   rewrites at the same target avoid repeated network discovery. Use\n   `--refresh-github-snapshot` after suspect API data, `--github-snapshot\n   \u003Cpath>` for an explicit artifact, or `--no-github-snapshot` for a live-only\n   audit. GitHub release bodies are always read live.\n   Explicit `CI #`, `CI run #`, `Actions run #`, and `workflow run #` references\n   in active source are classified separately only when issue\u002FPR resolution\n   fails and a live same-repository Actions lookup confirms the exact run ID.\n   Any ordinary occurrence of that number in active source, notes, or the\n   contribution record remains a strict issue\u002FPR requirement. Confirmed runs\n   appear as `workflowRuns` in verification output and the manifest, never as\n   PR associations or contributor credit.\n   Only GitHub `NOT_FOUND` references confined to contextual commit-body text, absent from subjects, closing references, provenance, and notes\u002Frecords, and below the highest resolved number may be omitted and reported as manifest `unavailableReferences` without credit.\n   - the manifest is the required input to the rewrite, not an after-the-fact\n     audit; it contains every referenced PR, eligible contributor credit,\n     inline issue context, every direct commit, and an editorial-eligibility\n     classification for PRs and direct commits\n   - schema version 3 is the required ephemeral manifest contract. Regenerate\n     older manifests; version 2 is not a supported downstream-reader boundary\n   - for a historical backfill, add `--seed-ref \u003Cpre-backfill-ref>` once so\n     contribution records from the prior changelog are retained even when an\n     older merged commit omitted its PR number; the verifier excludes records\n     for work reverted after the base tag, including beta work reverted before\n     the stable release\n   - generated provenance reports in-range PRs separately from retained\n     seed-only PRs, then states the unique row total. A PR present in both\n     inventories counts as in-range; never describe the seed-inclusive total\n     as work merged in the current release range\n   - add repeatable `--shipped-ref \u003Cprior-shipped-tag>` when the reachable main\n     closeout differs from the shipped tag or later forward-port commits\n     re-associate PRs that were already released. Each tag is a cumulative\n     shipped boundary: the verifier unions explicit PR rows from complete\n     contribution records in numbered release sections, excludes only overlapping PRs,\n     and ignores `Unreleased`. Never infer this boundary from the base SHA,\n     target prose, or target record. The manifest and generated provenance retain\n     each tag plus the exact excluded PR inventory and count for deterministic\n     candidate validation\n   - source PR discovery bounds GitHub commit associations to the selected target\n     history, or the frozen main history for canonical carriers. A contextual\n     source reference becomes a contribution only when its merged commit is\n     reachable in the target history and its merge time is within the target.\n     Keep all references resolvable, but do not promote unrelated PRs merely\n     because they merge while release preparation continues. Explicit seeds\n     retain their historical membership and remain seed-only unless independently\n     proven in-range. Resolve every association page; existing canonical,\n     cherry-pick, and provenance contracts remain authoritative.\n   - explicit multi-commit reverts require a revert subject and one standalone\n     `Reverts \u003Cfull SHA> and \u003Cfull SHA>.` declaration (comma-separated lists\n     with final `and` also work). The exact ending ` to restore the previous behavior.`\n     is accepted. Duplicate, abbreviated, embedded, or repeated declarations do\n     not establish reversal. Each named commit must be a single-parent ancestor,\n     and reverse-applying all named patches must reproduce the complete revert\n     tree. Recognized declarations that fail this proof stop verification. Proof\n     uses private Git index\u002Fobject storage without hooks or external diffs;\n     canonical single-revert and revert-of-revert accounting stays intact.\n   - canonicalize backports to the original merged PR on `main`: explicit\n     cherry-pick origins win, then a unique normalized-subject match requires\n     the same author and an overlapping changed path. Suppress release\u002Fbackport\n     PRs whenever the corresponding main PR exists on current `origin\u002Fmain`.\n     Keep a release-branch PR only when that change landed there first and has\n     not yet been forward-ported to `main`\n   - read the manifest before editing `### Highlights`, `### Changes`, or\n     `### Fixes`; do not carry old grouped prose forward without re-auditing it\n   - inspect linked PRs\u002Fissues or diffs for ambiguous commits. Direct commits\n     are editorial input, not public ledger rows; infer material user outcomes\n     from subject, body, touched files, tests, and nearby commits\n\n4. Rewrite one selected release section only:\n   - beta: `## YYYY.M.PATCH-beta.N`, containing only changes since the captured npm beta baseline\n   - stable: `## YYYY.M.PATCH`, cumulative since the previous stable baseline\n   - do not leave a stale `## Unreleased` section above the target release\n   - if `Unreleased` contains release-bound notes, fold them into the target\n     section instead of deleting them\n5. Section shape:\n   - `### Highlights`: 5-8 bullets for stable, 0-8 for a beta delta; do not invent highlights for small hotfix betas\n     - include only a clear user-visible capability or workflow unlock, a\n       material reliability\u002Fsafety fix, a broad cross-surface improvement, or\n       a release-defining integration\u002Fcompatibility milestone\n     - every highlight must say what changed for a user in one sentence; use\n       one user story per bullet and group its supporting PRs\n     - exclude tests, CI, refactors, docs, catalog churn, and implementation\n       detail unless the outcome is a material install\u002Fupdate, data-safety, or\n       widely visible user improvement\n   - `### Changes`: new capabilities and behavior changes\n   - `### Fixes`: user-facing fixes first, grouped by impact and surface\n   - group related changes\u002Ffixes by surface and user impact; avoid one bullet\n     per tiny commit when several commits tell one user-facing story\n   - `### Complete contribution record`: generated PR-first record after the\n     grouped prose; it is the exhaustive accounting surface, not a second\n     release summary\n6. Preserve verified attribution:\n   - PR authorship comes from the canonical GitHub PR, never the release commit\n     author, committer, or backport operator. Resolve coauthors from that PR's\n     original merge commit; release-carrier trailers and contextual mentions\n     do not establish credit on another PR\n   - rebuild generated thanks from PR, original coauthor, and linked-reporter\n     evidence. Seeds retain membership and references, not unverified old\n     thanks. Regeneration replaces stale generated credit in records and grouped\n     prose; verification rejects both missing and unsupported credit\n   - when a vanished PR meets the existing exact-SHA recovery contract, retain\n     its recorded thanks as historical credit without inventing a PR author\n   - keep `#issue`, `(#PR)`, `Fixes #...`, and `Thanks @...`\n   - every human-authored merged PR represented by a user-facing entry needs\n     its PR ref and `Thanks @author`, even when the PR had no linked issue\n   - every human issue reporter for a `Fixes #...` or referenced bug issue\n     represented by a user-facing entry needs `Thanks @reporter` unless the\n     same handle is already thanked in that bullet\n   - every human `Co-authored-by` contributor on represented user-facing work\n     needs `Thanks @handle` when a GitHub handle is known\n   - when grouping multiple PRs\u002Fissues in one bullet, include every relevant\n     PR\u002Fissue ref and every human contributor handle in that same bullet\n   - multiple `Thanks @...` handles in one bullet are expected; do not drop or\n     collapse contributor credit just because the note is grouped\n   - if one grouped bullet covers both direct commits and PRs, keep all PR refs\n     and thanks, plus any issue refs and human credit from the direct work\n   - issues remain normal inline `#NNN` references. Do not add a separate\n     linked-issues inventory. The generated PR record keeps source issues\n     inline as `Related #NNN` on the PR that shipped them\n   - when backfilling an older linked-issues inventory, preserve reporter\n     credit inline for every GitHub-confirmed closing PR relationship. Do not\n     infer a PR relationship from a generic cross-reference event, invent an\n     unrelated PR link for a standalone report, or recreate the retired\n     inventory\n   - the complete contribution record lists every verified in-range PR and\n     explicitly retained seed-only PR exactly once as `**PR #NNN**`. Discovery\n     preserves canonical\u002Fcherry-pick provenance and requires frozen-history\n     membership for contextual references; inline context alone cannot create a\n     contribution row. It preserves author\u002Fco-author credit and any issue\n     references in the original title\n   - the provenance arithmetic and unique total must match the rendered PR\n     rows exactly; candidate validation rejects malformed or forged counts\n   - direct commits remain in the manifest with GitHub-resolved author,\n     co-author, issue, and editorial-eligibility data. They inform grouped\n     prose but are never rendered as a public `#### Direct commits` dump. Add\n     direct-commit credit to a grouped bullet only when it shares an explicit\n     closing issue reference or at least two distinctive subject terms\n   - the verifier rejects ordinary `docs`, `test`, `refactor`, `ci`, `build`,\n     `chore`, and `style` PRs in Highlights, Changes, or Fixes. An explicit\n     Conventional Commits `!` marker makes any type editorial-eligible; include\n     its verified user-facing breaking change and migration guidance with the\n     original PR ref and credit. Keep other internal contributions only in the\n     complete PR record\n   - classify conventional titles from their declared type and scope, not\n     incidental words such as `doc` or `build` in their descriptions. For\n     untyped titles, retain internal-work signals such as `QA`, `test`, `docs`,\n     `refactor`, `lint`, or `CI`; eligibility never replaces the source audit\n     that establishes a user-visible outcome\n   - do not add GHSA references, advisory IDs, or security advisory slugs to\n     changelog entries or GitHub release-note text unless explicitly requested\n   - credit verified human authors, including maintainers such as `@steipete`.\n     Never thank bots, known automation accounts such as `@steipete-oai`,\n     `@claude`, `@codex`, `@openclaw`, or `@clawsweeper`\n   - do not use GitHub's release contributor count as the source of truth; the\n     changelog must carry the complete human credit set itself\n7. Sorting preference:\n   - security\u002Fdata-loss and content-boundary fixes\n   - transcript\u002Freplay\u002Freply delivery correctness\n   - channels and mobile integrations\n   - providers\u002FCodex\u002Flocal model reliability\n   - install\u002Fupdate\u002Frelease path reliability\n   - performance and observability\n   - docs and contributor-only\u002Finternal details last or omitted\n8. Keep bullets single-line unless existing file style forces otherwise. Avoid\n   internal release-process noise unless it changes user install\u002Fupdate safety.\n9. Check release-note side conditions:\n   - inspect `src\u002Fplugins\u002Fcompat\u002Fregistry.ts`\n   - inspect `src\u002Fcommands\u002Fdoctor\u002Fshared\u002Fdeprecation-compat.ts`\n   - if a deprecated compatibility record reaches `removeAfter`, remove it when\n     proven safe or move it to `removal-pending` and record the blocker; keep a\n     due `removal-pending` record only until its documented conditions are met\n10. Validate and ship:\n\n- after the manifest-driven rewrite, regenerate and verify the complete\n  contribution record before committing:\n  ```bash\n  node --import tsx .agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs \\\n    --base \u003Cbase-tag> \\\n    --target \u003Ctarget-ref> \\\n    --main-ref origin\u002Fmain \\\n    --version \u003CYYYY.M.PATCH> \\\n    --manifest \u002Ftmp\u002Fopenclaw-release-\u003CYYYY.M.PATCH>.json \\\n    --write-ledger\n  ```\n- the command fails when any `#NNN` reference in release history or the\n  rendered release section cannot resolve, when reverted work is presented\n  as shipped, when a source PR is absent from the contribution record, when\n  direct commits are rendered as a public record dump, when non-editorial\n  PRs appear in grouped prose, or when an eligible PR author or known\n  co-author is missing from that PR's `Thanks @...` credit, or unsupported\n  credit appears in its record or represented editorial bullet. It also fails\n  before history collection when `--base` is not an ancestor of `--target`\n  (except beta release tags normalized to merge-base plus shipped-record subtraction),\n  when `### Highlights` violates the selected stable (5-8) or beta (0-8)\n  top-level bullet budget, or when the existing prose\u002Frecord names a PR outside the source\n  range. Only an explicit `--seed-ref` may add historical PR inventory; an\n  explicit repeatable `--shipped-ref` may subtract PRs proven present in a\n  prior shipped tag\n- when grouped prose names a PR, that same bullet must retain every\n  contributor and linked-reporter credit from its generated PR record\n- unqualified `#NNN` references resolve against `openclaw\u002Fopenclaw`;\n  cross-repository references such as `openclaw\u002Fimsg#141` remain literal\n  text and must not be rewritten as local issue links\n- after the GitHub release or prerelease is published, verify every matching\n  release page against the same source section:\n  ```bash\n  node --import tsx .agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs \\\n    --base \u003Cbase-tag> \\\n    --target \u003Ctarget-ref> \\\n    --version \u003CYYYY.M.PATCH> \\\n    --release-tag v\u003CYYYY.M.PATCH> \\\n    --check-github\n  ```\n- verify each beta page with its exact beta version, captured base and target;\n  verify stable and extended-stable with their own source section and range.\n  Extended-stable verification also requires\n  `--regular-stable-version \u003Ccurrent-regular-stable-version>` so the canonical\n  release notice is checked against its immutable regular-stable context.\n  Never compare multiple beta pages against one cumulative stable section.\n  A `### Release verification` tail is permitted; other body drift fails.\n- `scripts\u002Frender-github-release-notes.mts` is the canonical release-body\n  renderer used by candidate validation, publish, and verification. When the\n  complete selected version section fits GitHub's 125,000-character limit and\n  the renderer's matching 125,000-byte safety ceiling, the body must contain\n  that exact section including its heading\n- when the complete source section exceeds either limit, the renderer keeps the exact\n  grouped editorial notes through the line before\n  `### Complete contribution record`, then emits that heading with a stable\n  link to the full contribution record in the tag-pinned\n  `CHANGELOG\u002Frecords\u002F\u003Cversion>.md` (historical monolithic tags retain their\n  original `CHANGELOG.md` record link).\n  Never truncate a bullet or partial record, and never hand-author a different\n  compact form\n- append `### Release verification` only when it fits after the canonical full\n  or compact body is chosen. If it does not fit, omit the body tail and retain\n  the immutable attached release evidence; never compact a fitting full\n  contribution record just to preserve the optional tail\n- `pnpm release:candidate` performs this deterministic render check from the\n  exact target before it dispatches Full Release Validation, including when local\n  generated checks are explicitly skipped\n- `git diff --check`\n- `pnpm changelog:check` validates the split index, records, and marked docs mirrors\n- for docs\u002Fchangelog-only changes, no broad tests are required\n- stage the target release entry, its generated record, and changed index; commit with `git commit -m \"docs(changelog): refresh YYYY.M.PATCH notes\"`\n- push the release branch without rebasing it onto moving `main`\n- when all fixes and final notes are committed before fresh full qualification,\n  record that commit as both Code SHA and Release SHA; use the same successful\n  full parent\u002Fattempt and its exact publication bytes for both roles\n- only when notes change after Code qualification, require\n  `git diff --name-only \u003Ccode-sha>..\u003Crelease-sha>` to include\n  `CHANGELOG\u002F\u003Cversion>.md` and only that entry, its matching record, and\n  `CHANGELOG.md` before optionally using `split-changelog-release-v1`. Additions\n  or modifications of the selected entry\u002Frecord are allowed; renames, deletions,\n  other releases, and docs source changes are not. Historical root-only receipts\n  retain `changelog-only-release-v1`. The split path\n  retains green Code proof and qualifies new Release SHA package bytes. Any\n  other changed path requires fresh product qualification\n\n## Post-release docs mirrors\n\nAfter explicit approval of the docs publication, publish the approved docs\nsources and their mechanically flattened changelog in the same source PR.\nThis is separate from initial release generation; do not run an editorial\nrewrite automatically during release preparation or publication.\n\nRender the ordered docs sources into one full Markdown file, even for a large\nrelease or a release spanning several docs pages:\n\n```bash\npnpm changelog:from-docs --version YYYY.M.PATCH \\\n  --source docs\u002Freleases\u002FYYYY.M.PATCH.md \\\n  --output CHANGELOG\u002FYYYY.M.PATCH.md\npnpm changelog:check\n```\n\nRepeat `--source` in the approved reading order for a multipart release. The\nconverter removes presentation wrappers, turns accordion titles into headings,\nexpands docs links, and preserves source text, credits, code, tables, and images.\nUnsupported markup fails instead of silently dropping content. Its first-line\nmarker binds the ordered source paths and exact source digest. Checks compare\nonly marked mirrors against their sources; untouched historical originals stay\nin their initial format. Preserve `CHANGELOG\u002Frecords\u002FYYYY.M.PATCH.md` as the\nfrozen accounting record when replacing reader prose, and regenerate the mirror\nin the same PR whenever its docs sources change.\n\nThe approved publication bundle owns source merge, verified docs deployment,\nand the later GitHub Release body update as separate recorded steps. After\ndeployment, freshly read the existing release, then update only its body with\nversion\u002Fstatistics, Raw changelog and docs links, one alphabetically deduplicated\nverified human thanks roster, and the unchanged release-verification section.\nInclude verified PR, direct-commit, coauthor, and issue credit, including\n`@steipete`; exclude bots. Keep both the 125,000-character and 125,000-byte\nceilings without truncating credits or proof. GitHub owns native avatars and\nassets. Verify the body readback, resume only incomplete steps, and never retag,\nrebuild, republish assets, or rerun initial publication to replace this body.\nThe initial history verifier rejects docs mirrors; use the docs-publication\nworkflow for their verification.\n\n## Extended-Stable Variant\n\nExtended-stable has one release commit and one canonical GitHub Release body.\nAfter version prep and approved backports, regenerate `CHANGELOG\u002FYYYY.M.P.md`\nwith the regular manifest and original-main-PR provenance rules. Commit it directly\nto the canonical release branch, then validate the final branch tip before tagging.\nDo not open a staging\u002Fbackport PR for release preparation. The release closeout\nrenders that tag-owned section into the shared draft before the parent pipeline publishes\nthe non-Latest release page. Re-audit after a product\nbackport; a tooling-only repair needs no changelog entry. Never rewrite a\npublished tag or changelog.\n\n## Quota \u002F API Outage Rule\n\nIf GitHub API quota is exhausted, do not idle. Continue work that does not need\nGitHub API:\n\n- local changelog rewrite and release-note extraction\n- local pretag checks and package\u002Fbuild sanity\n- git push\u002Ftag checks over git protocol\n- npm registry `npm view` checks\n- exact workflow-dispatch command preparation\n\nOnly GitHub Release creation, workflow dispatch, run polling, artifact download,\nand issue\u002FPR mutation need API quota.\n","# OpenClaw Changelog Update\n\nUse this for changelog rewrites and GitHub release-note source text. For regular\nbeta\u002Fstable, prepare complete notes before final-source qualification when\npossible; Code SHA may then also be Release SHA. Editorial work may overlap\nCode validation. Do not rerun it per validation-recovery backport; when backports\nreplace the Code SHA, rerun it once after the final Code SHA is green, as a\ngenuine CHANGELOG-only descendant under the existing product-evidence reuse\npolicy ([timing](..\u002Frelease-openclaw-maintainer\u002Freferences\u002Fpreparation.md#changelog-and-release-notes)). For\nextended-stable, run it before final exact-head validation and tagging. Do not\nrerun it for tooling retries, resumed publication, or promotion.\nUse it with `release-openclaw-maintainer`; this skill owns changelog content,\nordering, grouping, and attribution discipline.\n\n## Goal\n\nRebuild the target `CHANGELOG\u002F\u003Cversion>.md` release section from a complete, generated\nhistory manifest, not stale draft notes. Produce grouped user-facing release\nnotes sorted by user interest while preserving every relevant issue\u002FPR ref and\nevery verified human `Thanks @...` attribution.\n\n`CHANGELOG.md` is the generated release index. The shared owner\n`scripts\u002Flib\u002Frelease-changelog.mjs` resolves release sections and contribution\nrecords from a working tree or a pinned Git ref, including historical refs\nthat still contain a monolith. Use `node scripts\u002Frelease-changelog.mjs read\n--version \u003Cversion> [--ref \u003Csha-or-tag>]` for a section, or add `--record` for\nits contribution record. A missing split artifact must not fall back to the\nroot index. Historical releases without records gain no invented provenance.\nGenerated `CHANGELOG\u002F**` files retain exact migrated or mirrored bytes and are\nexcluded from generic formatting, like the root changelog. Validate them through\ntheir owner with `pnpm changelog:check`.\n\nCurrent writes use the split layout. To save a complete initial section, use\n`node scripts\u002Frelease-changelog.mjs write --version \u003Cversion> --file \u003Csection.md>`;\nit updates the release entry, matching `CHANGELOG\u002Frecords\u002F\u003Cversion>.md` when\npresent, and index together. Initial generation retains the section format\nbelow. Published docs mirrors follow the separate post-release route at the end\nof this skill; initial generation must never overwrite them.\n\n## Inputs\n\n- Target version: exact `YYYY.M.PATCH-beta.N` for a beta delta; `YYYY.M.PATCH`\n  for cumulative stable notes. Beta entries and records are separate frozen\n  artifacts, never copies of the stable-base section.\n- Beta base tag: capture the version currently selected by public npm\n  `openclaw@beta` before publication, not the last GitHub prerelease or the\n  highest beta-suffixed version. The selector may name a stable version also\n  selected by `latest`. Omit `--base` (or use `--base npm-beta`) with an exact\n  beta version to resolve it once; preserve the resolved tag from the generated\n  manifest and reuse that explicit `--base` for edits, verification and recovery.\n  If npm already selects the candidate or a newer version, generation refuses\n  to guess historical selector state; supply the previously captured tag. When\n  that tag is not an ancestor (for example a stable closeout forward-port), the\n  verifier uses its reachable merge base and subtracts the captured shipped\n  tag's cumulative PR record through `--shipped-ref` semantics. The manifest and\n  record retain both boundaries; replay with the captured tag to resolve the\n  same range, never select an older GitHub beta instead.\n- Stable base tag: last reachable shipped stable release tag. It must be an ancestor of\n  the target; a newer but divergent tag is not a valid history boundary. Use\n  an explicit shipped\u002Fmain-closeout SHA only when it is also reachable from the\n  target.\n- Target ref: the exact product-complete history being documented. Its\n  contribution-record target must be an ancestor of the final release target;\n  it need not name a not-yet-created changelog commit. Include any later fixes\n  before finalizing notes. Final notes may be committed before qualification,\n  or afterward as a CHANGELOG-only descendant of a green Code SHA.\n- Canonical main ref: current `origin\u002Fmain`, fetched before verification. Release\n  notes cite the original merged main PR when the same work is carried by a\n  backport. A release-branch PR is used only while no forward-port exists on\n  current main.\n\n## Workflow\n\n1. Confirm the release branch and exact history target:\n   - `git fetch --tags origin`\n   - confirm clean `git status -sb`\n   - record `git rev-parse HEAD` as the history target\n   - record the Full Release Validation run id and attempt when qualification already exists\n   - finish pending product\u002Fversion\u002Fbackport changes before freezing final source; refresh the inventory for actual changes\n2. Audit history, including direct commits:\n   - `git log --topo-order --date=iso-strict --pretty=format:'%h%x09%ad%x09%s' \u003Cbase-tag>..\u003Ctarget-ref>`\n   - `git log --topo-order --grep='(#' --date=short --pretty=format:'%h%x09%ad%x09%s' \u003Cbase-tag>..\u003Ctarget-ref>`\n   - Include every commit reachable from the target but not the base, including merged side branches. Resolve PR associations before deduplicating and subtracting shipped records; retain the existing revert exclusions.\n   - also inspect `--since='24 hours ago'` when main moved during the release.\n3. Generate the complete contribution record and editorial manifest before\n   writing grouped prose:\n\n   ```bash\n   node --import tsx .agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs \\\n     --base \u003Cbase-tag> \\\n     --target \u003Ctarget-ref> \\\n     --release-branch \u003Ccanonical-release-branch> \\\n     --main-ref origin\u002Fmain \\\n     --version \u003CYYYY.M.PATCH> \\\n     --manifest \u002Ftmp\u002Fopenclaw-release-\u003CYYYY.M.PATCH>.json \\\n     --write-ledger\n   ```\n\n   For beta generation, use `--version YYYY.M.PATCH-beta.N` and omit `--base`\n   on the first inventory run. Start an exact-version section with Highlights,\n   Changes and Fixes using the shared writer; generate the delta manifest, then\n   write prose for that range only. Subsequent runs use the captured npm baseline\n   tag explicitly (not only a divergent range's merge-base SHA). Do not query npm again after publication or overwrite the\n   cumulative stable entry. Regenerate cumulative stable notes at stable prep.\n\n   Add repeatable `--release-provenance '\u003C40sha> -> #PR[, #PR]'` inputs when\n   release commits cannot carry provenance metadata. These use the same exact\n   marker grammar and source validation as commit-body markers. A merged\n   release-branch original is valid only while no corresponding current-main\n   forward-port exists; its GitHub merge commit pins the original source.\n\n   The verifier automatically reuses public GitHub GraphQL responses from an\n   exact base\u002Ftarget SHA snapshot under the worktree's git metadata. Iterative\n   rewrites at the same target avoid repeated network discovery. Use\n   `--refresh-github-snapshot` after suspect API data, `--github-snapshot\n   \u003Cpath>` for an explicit artifact, or `--no-github-snapshot` for a live-only\n   audit. GitHub release bodies are always read live.\n   Explicit `CI #`, `CI run #`, `Actions run #`, and `workflow run #` references\n   in active source are classified separately only when issue\u002FPR resolution\n   fails and a live same-repository Actions lookup confirms the exact run ID.\n   Any ordinary occurrence of that number in active source, notes, or the\n   contribution record remains a strict issue\u002FPR requirement. Confirmed runs\n   appear as `workflowRuns` in verification output and the manifest, never as\n   PR associations or contributor credit.\n   Only GitHub `NOT_FOUND` references confined to contextual commit-body text, absent from subjects, closing references, provenance, and notes\u002Frecords, and below the highest resolved number may be omitted and reported as manifest `unavailableReferences` without credit.\n   - the manifest is the required input to the rewrite, not an after-the-fact\n     audit; it contains every referenced PR, eligible contributor credit,\n     inline issue context, every direct commit, and an editorial-eligibility\n     classification for PRs and direct commits\n   - schema version 3 is the required ephemeral manifest contract. Regenerate\n     older manifests; version 2 is not a supported downstream-reader boundary\n   - for a historical backfill, add `--seed-ref \u003Cpre-backfill-ref>` once so\n     contribution records from the prior changelog are retained even when an\n     older merged commit omitted its PR number; the verifier excludes records\n     for work reverted after the base tag, including beta work reverted before\n     the stable release\n   - generated provenance reports in-range PRs separately from retained\n     seed-only PRs, then states the unique row total. A PR present in both\n     inventories counts as in-range; never describe the seed-inclusive total\n     as work merged in the current release range\n   - add repeatable `--shipped-ref \u003Cprior-shipped-tag>` when the reachable main\n     closeout differs from the shipped tag or later forward-port commits\n     re-associate PRs that were already released. Each tag is a cumulative\n     shipped boundary: the verifier unions explicit PR rows from complete\n     contribution records in numbered release sections, excludes only overlapping PRs,\n     and ignores `Unreleased`. Never infer this boundary from the base SHA,\n     target prose, or target record. The manifest and generated provenance retain\n     each tag plus the exact excluded PR inventory and count for deterministic\n     candidate validation\n   - source PR discovery bounds GitHub commit associations to the selected target\n     history, or the frozen main history for canonical carriers. A contextual\n     source reference becomes a contribution only when its merged commit is\n     reachable in the target history and its merge time is within the target.\n     Keep all references resolvable, but do not promote unrelated PRs merely\n     because they merge while release preparation continues. Explicit seeds\n     retain their historical membership and remain seed-only unless independently\n     proven in-range. Resolve every association page; existing canonical,\n     cherry-pick, and provenance contracts remain authoritative.\n   - explicit multi-commit reverts require a revert subject and one standalone\n     `Reverts \u003Cfull SHA> and \u003Cfull SHA>.` declaration (comma-separated lists\n     with final `and` also work). The exact ending ` to restore the previous behavior.`\n     is accepted. Duplicate, abbreviated, embedded, or repeated declarations do\n     not establish reversal. Each named commit must be a single-parent ancestor,\n     and reverse-applying all named patches must reproduce the complete revert\n     tree. Recognized declarations that fail this proof stop verification. Proof\n     uses private Git index\u002Fobject storage without hooks or external diffs;\n     canonical single-revert and revert-of-revert accounting stays intact.\n   - canonicalize backports to the original merged PR on `main`: explicit\n     cherry-pick origins win, then a unique normalized-subject match requires\n     the same author and an overlapping changed path. Suppress release\u002Fbackport\n     PRs whenever the corresponding main PR exists on current `origin\u002Fmain`.\n     Keep a release-branch PR only when that change landed there first and has\n     not yet been forward-ported to `main`\n   - read the manifest before editing `### Highlights`, `### Changes`, or\n     `### Fixes`; do not carry old grouped prose forward without re-auditing it\n   - inspect linked PRs\u002Fissues or diffs for ambiguous commits. Direct commits\n     are editorial input, not public ledger rows; infer material user outcomes\n     from subject, body, touched files, tests, and nearby commits\n\n4. Rewrite one selected release section only:\n   - beta: `## YYYY.M.PATCH-beta.N`, containing only changes since the captured npm beta baseline\n   - stable: `## YYYY.M.PATCH`, cumulative since the previous stable baseline\n   - do not leave a stale `## Unreleased` section above the target release\n   - if `Unreleased` contains release-bound notes, fold them into the target\n     section instead of deleting them\n5. Section shape:\n   - `### Highlights`: 5-8 bullets for stable, 0-8 for a beta delta; do not invent highlights for small hotfix betas\n     - include only a clear user-visible capability or workflow unlock, a\n       material reliability\u002Fsafety fix, a broad cross-surface improvement, or\n       a release-defining integration\u002Fcompatibility milestone\n     - every highlight must say what changed for a user in one sentence; use\n       one user story per bullet and group its supporting PRs\n     - exclude tests, CI, refactors, docs, catalog churn, and implementation\n       detail unless the outcome is a material install\u002Fupdate, data-safety, or\n       widely visible user improvement\n   - `### Changes`: new capabilities and behavior changes\n   - `### Fixes`: user-facing fixes first, grouped by impact and surface\n   - group related changes\u002Ffixes by surface and user impact; avoid one bullet\n     per tiny commit when several commits tell one user-facing story\n   - `### Complete contribution record`: generated PR-first record after the\n     grouped prose; it is the exhaustive accounting surface, not a second\n     release summary\n6. Preserve verified attribution:\n   - PR authorship comes from the canonical GitHub PR, never the release commit\n     author, committer, or backport operator. Resolve coauthors from that PR's\n     original merge commit; release-carrier trailers and contextual mentions\n     do not establish credit on another PR\n   - rebuild generated thanks from PR, original coauthor, and linked-reporter\n     evidence. Seeds retain membership and references, not unverified old\n     thanks. Regeneration replaces stale generated credit in records and grouped\n     prose; verification rejects both missing and unsupported credit\n   - when a vanished PR meets the existing exact-SHA recovery contract, retain\n     its recorded thanks as historical credit without inventing a PR author\n   - keep `#issue`, `(#PR)`, `Fixes #...`, and `Thanks @...`\n   - every human-authored merged PR represented by a user-facing entry needs\n     its PR ref and `Thanks @author`, even when the PR had no linked issue\n   - every human issue reporter for a `Fixes #...` or referenced bug issue\n     represented by a user-facing entry needs `Thanks @reporter` unless the\n     same handle is already thanked in that bullet\n   - every human `Co-authored-by` contributor on represented user-facing work\n     needs `Thanks @handle` when a GitHub handle is known\n   - when grouping multiple PRs\u002Fissues in one bullet, include every relevant\n     PR\u002Fissue ref and every human contributor handle in that same bullet\n   - multiple `Thanks @...` handles in one bullet are expected; do not drop or\n     collapse contributor credit just because the note is grouped\n   - if one grouped bullet covers both direct commits and PRs, keep all PR refs\n     and thanks, plus any issue refs and human credit from the direct work\n   - issues remain normal inline `#NNN` references. Do not add a separate\n     linked-issues inventory. The generated PR record keeps source issues\n     inline as `Related #NNN` on the PR that shipped them\n   - when backfilling an older linked-issues inventory, preserve reporter\n     credit inline for every GitHub-confirmed closing PR relationship. Do not\n     infer a PR relationship from a generic cross-reference event, invent an\n     unrelated PR link for a standalone report, or recreate the retired\n     inventory\n   - the complete contribution record lists every verified in-range PR and\n     explicitly retained seed-only PR exactly once as `**PR #NNN**`. Discovery\n     preserves canonical\u002Fcherry-pick provenance and requires frozen-history\n     membership for contextual references; inline context alone cannot create a\n     contribution row. It preserves author\u002Fco-author credit and any issue\n     references in the original title\n   - the provenance arithmetic and unique total must match the rendered PR\n     rows exactly; candidate validation rejects malformed or forged counts\n   - direct commits remain in the manifest with GitHub-resolved author,\n     co-author, issue, and editorial-eligibility data. They inform grouped\n     prose but are never rendered as a public `#### Direct commits` dump. Add\n     direct-commit credit to a grouped bullet only when it shares an explicit\n     closing issue reference or at least two distinctive subject terms\n   - the verifier rejects ordinary `docs`, `test`, `refactor`, `ci`, `build`,\n     `chore`, and `style` PRs in Highlights, Changes, or Fixes. An explicit\n     Conventional Commits `!` marker makes any type editorial-eligible; include\n     its verified user-facing breaking change and migration guidance with the\n     original PR ref and credit. Keep other internal contributions only in the\n     complete PR record\n   - classify conventional titles from their declared type and scope, not\n     incidental words such as `doc` or `build` in their descriptions. For\n     untyped titles, retain internal-work signals such as `QA`, `test`, `docs`,\n     `refactor`, `lint`, or `CI`; eligibility never replaces the source audit\n     that establishes a user-visible outcome\n   - do not add GHSA references, advisory IDs, or security advisory slugs to\n     changelog entries or GitHub release-note text unless explicitly requested\n   - credit verified human authors, including maintainers such as `@steipete`.\n     Never thank bots, known automation accounts such as `@steipete-oai`,\n     `@claude`, `@codex`, `@openclaw`, or `@clawsweeper`\n   - do not use GitHub's release contributor count as the source of truth; the\n     changelog must carry the complete human credit set itself\n7. Sorting preference:\n   - security\u002Fdata-loss and content-boundary fixes\n   - transcript\u002Freplay\u002Freply delivery correctness\n   - channels and mobile integrations\n   - providers\u002FCodex\u002Flocal model reliability\n   - install\u002Fupdate\u002Frelease path reliability\n   - performance and observability\n   - docs and contributor-only\u002Finternal details last or omitted\n8. Keep bullets single-line unless existing file style forces otherwise. Avoid\n   internal release-process noise unless it changes user install\u002Fupdate safety.\n9. Check release-note side conditions:\n   - inspect `src\u002Fplugins\u002Fcompat\u002Fregistry.ts`\n   - inspect `src\u002Fcommands\u002Fdoctor\u002Fshared\u002Fdeprecation-compat.ts`\n   - if a deprecated compatibility record reaches `removeAfter`, remove it when\n     proven safe or move it to `removal-pending` and record the blocker; keep a\n     due `removal-pending` record only until its documented conditions are met\n10. Validate and ship:\n\n- after the manifest-driven rewrite, regenerate and verify the complete\n  contribution record before committing:\n  ```bash\n  node --import tsx .agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs \\\n    --base \u003Cbase-tag> \\\n    --target \u003Ctarget-ref> \\\n    --main-ref origin\u002Fmain \\\n    --version \u003CYYYY.M.PATCH> \\\n    --manifest \u002Ftmp\u002Fopenclaw-release-\u003CYYYY.M.PATCH>.json \\\n    --write-ledger\n  ```\n- the command fails when any `#NNN` reference in release history or the\n  rendered release section cannot resolve, when reverted work is presented\n  as shipped, when a source PR is absent from the contribution record, when\n  direct commits are rendered as a public record dump, when non-editorial\n  PRs appear in grouped prose, or when an eligible PR author or known\n  co-author is missing from that PR's `Thanks @...` credit, or unsupported\n  credit appears in its record or represented editorial bullet. It also fails\n  before history collection when `--base` is not an ancestor of `--target`\n  (except beta release tags normalized to merge-base plus shipped-record subtraction),\n  when `### Highlights` violates the selected stable (5-8) or beta (0-8)\n  top-level bullet budget, or when the existing prose\u002Frecord names a PR outside the source\n  range. Only an explicit `--seed-ref` may add historical PR inventory; an\n  explicit repeatable `--shipped-ref` may subtract PRs proven present in a\n  prior shipped tag\n- when grouped prose names a PR, that same bullet must retain every\n  contributor and linked-reporter credit from its generated PR record\n- unqualified `#NNN` references resolve against `openclaw\u002Fopenclaw`;\n  cross-repository references such as `openclaw\u002Fimsg#141` remain literal\n  text and must not be rewritten as local issue links\n- after the GitHub release or prerelease is published, verify every matching\n  release page against the same source section:\n  ```bash\n  node --import tsx .agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs \\\n    --base \u003Cbase-tag> \\\n    --target \u003Ctarget-ref> \\\n    --version \u003CYYYY.M.PATCH> \\\n    --release-tag v\u003CYYYY.M.PATCH> \\\n    --check-github\n  ```\n- verify each beta page with its exact beta version, captured base and target;\n  verify stable and extended-stable with their own source section and range.\n  Extended-stable verification also requires\n  `--regular-stable-version \u003Ccurrent-regular-stable-version>` so the canonical\n  release notice is checked against its immutable regular-stable context.\n  Never compare multiple beta pages against one cumulative stable section.\n  A `### Release verification` tail is permitted; other body drift fails.\n- `scripts\u002Frender-github-release-notes.mts` is the canonical release-body\n  renderer used by candidate validation, publish, and verification. When the\n  complete selected version section fits GitHub's 125,000-character limit and\n  the renderer's matching 125,000-byte safety ceiling, the body must contain\n  that exact section including its heading\n- when the complete source section exceeds either limit, the renderer keeps the exact\n  grouped editorial notes through the line before\n  `### Complete contribution record`, then emits that heading with a stable\n  link to the full contribution record in the tag-pinned\n  `CHANGELOG\u002Frecords\u002F\u003Cversion>.md` (historical monolithic tags retain their\n  original `CHANGELOG.md` record link).\n  Never truncate a bullet or partial record, and never hand-author a different\n  compact form\n- append `### Release verification` only when it fits after the canonical full\n  or compact body is chosen. If it does not fit, omit the body tail and retain\n  the immutable attached release evidence; never compact a fitting full\n  contribution record just to preserve the optional tail\n- `pnpm release:candidate` performs this deterministic render check from the\n  exact target before it dispatches Full Release Validation, including when local\n  generated checks are explicitly skipped\n- `git diff --check`\n- `pnpm changelog:check` validates the split index, records, and marked docs mirrors\n- for docs\u002Fchangelog-only changes, no broad tests are required\n- stage the target release entry, its generated record, and changed index; commit with `git commit -m \"docs(changelog): refresh YYYY.M.PATCH notes\"`\n- push the release branch without rebasing it onto moving `main`\n- when all fixes and final notes are committed before fresh full qualification,\n  record that commit as both Code SHA and Release SHA; use the same successful\n  full parent\u002Fattempt and its exact publication bytes for both roles\n- only when notes change after Code qualification, require\n  `git diff --name-only \u003Ccode-sha>..\u003Crelease-sha>` to include\n  `CHANGELOG\u002F\u003Cversion>.md` and only that entry, its matching record, and\n  `CHANGELOG.md` before optionally using `split-changelog-release-v1`. Additions\n  or modifications of the selected entry\u002Frecord are allowed; renames, deletions,\n  other releases, and docs source changes are not. Historical root-only receipts\n  retain `changelog-only-release-v1`. The split path\n  retains green Code proof and qualifies new Release SHA package bytes. Any\n  other changed path requires fresh product qualification\n\n## Post-release docs mirrors\n\nAfter explicit approval of the docs publication, publish the approved docs\nsources and their mechanically flattened changelog in the same source PR.\nThis is separate from initial release generation; do not run an editorial\nrewrite automatically during release preparation or publication.\n\nRender the ordered docs sources into one full Markdown file, even for a large\nrelease or a release spanning several docs pages:\n\n```bash\npnpm changelog:from-docs --version YYYY.M.PATCH \\\n  --source docs\u002Freleases\u002FYYYY.M.PATCH.md \\\n  --output CHANGELOG\u002FYYYY.M.PATCH.md\npnpm changelog:check\n```\n\nRepeat `--source` in the approved reading order for a multipart release. The\nconverter removes presentation wrappers, turns accordion titles into headings,\nexpands docs links, and preserves source text, credits, code, tables, and images.\nUnsupported markup fails instead of silently dropping content. Its first-line\nmarker binds the ordered source paths and exact source digest. Checks compare\nonly marked mirrors against their sources; untouched historical originals stay\nin their initial format. Preserve `CHANGELOG\u002Frecords\u002FYYYY.M.PATCH.md` as the\nfrozen accounting record when replacing reader prose, and regenerate the mirror\nin the same PR whenever its docs sources change.\n\nThe approved publication bundle owns source merge, verified docs deployment,\nand the later GitHub Release body update as separate recorded steps. After\ndeployment, freshly read the existing release, then update only its body with\nversion\u002Fstatistics, Raw changelog and docs links, one alphabetically deduplicated\nverified human thanks roster, and the unchanged release-verification section.\nInclude verified PR, direct-commit, coauthor, and issue credit, including\n`@steipete`; exclude bots. Keep both the 125,000-character and 125,000-byte\nceilings without truncating credits or proof. GitHub owns native avatars and\nassets. Verify the body readback, resume only incomplete steps, and never retag,\nrebuild, republish assets, or rerun initial publication to replace this body.\nThe initial history verifier rejects docs mirrors; use the docs-publication\nworkflow for their verification.\n\n## Extended-Stable Variant\n\nExtended-stable has one release commit and one canonical GitHub Release body.\nAfter version prep and approved backports, regenerate `CHANGELOG\u002FYYYY.M.P.md`\nwith the regular manifest and original-main-PR provenance rules. Commit it directly\nto the canonical release branch, then validate the final branch tip before tagging.\nDo not open a staging\u002Fbackport PR for release preparation. The release closeout\nrenders that tag-owned section into the shared draft before the parent pipeline publishes\nthe non-Latest release page. Re-audit after a product\nbackport; a tooling-only repair needs no changelog entry. Never rewrite a\npublished tag or changelog.\n\n## Quota \u002F API Outage Rule\n\nIf GitHub API quota is exhausted, do not idle. Continue work that does not need\nGitHub API:\n\n- local changelog rewrite and release-note extraction\n- local pretag checks and package\u002Fbuild sanity\n- git push\u002Ftag checks over git protocol\n- npm registry `npm view` checks\n- exact workflow-dispatch command preparation\n\nOnly GitHub Release creation, workflow dispatch, run polling, artifact download,\nand issue\u002FPR mutation need API quota.\n",{"name":5,"description":7},"main","c37e3897be60e2db9db3aefba9cee92bcb193b51",".agents\u002Fskills\u002Fopenclaw-changelog-update",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":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add openclaw\u002Fopenclaw --skill openclaw-changelog-update",{"tool":48,"command":49},"bunx","bunx skills add openclaw\u002Fopenclaw --skill openclaw-changelog-update",{"tool":51,"command":52},"pnpm","pnpm dlx skills add openclaw\u002Fopenclaw --skill openclaw-changelog-update","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-changelog-update\u002FSKILL.md",true,[56],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"scripts\u002Fverify-release-notes.mjs","SCRIPT","脚本",108962,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-changelog-update\u002Fscripts\u002Fverify-release-notes.mjs",[63,69,92,110,132,156],{"skillNo":64,"name":65,"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":66,"categories":67,"keywords":68,"publishedAt":28},"01M698VP84FNM6G9MR1HPX7MF7","lobster","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Flobster\u002FSKILL.md",[],[65],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":28},"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",[],[71,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91],"for","api","calls","replies","posts","upload","tap","install","brew","node","Media","search","npm","status","auth","cli",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":28},"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",[],[94,99,100,83,101,84,102,103,104,105,106,107,76,108,109],"travel planning","travel","fetch","curl","https","help","planning","web","back","temperature","with",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":121,"publishedAt":28},"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",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[112,122,123,124,125,76,109,126,127,128,129,130,9,131],"widgets","openclaw dashboard","author","inline","show","code","create","visuals","dashboard","widget",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":146,"publishedAt":28},"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",[138,143],{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":144,"categoryName":145,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000030","开发工程师",[134,103,147,148,149,150,151,152,83,84,153,102,77,154,155],"cloud","manage","via","rest api","token","atlassian","jq","REST","developer",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":28},"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",[],[158,83,163,164,76,165,166,167,168,169,170,171,84,172,173,174,175,176,177],"send","darwin","keys","paste","output","control","prompts","interactive","list","capture","panes","text","monitor","sessions","linux"]