diff --git a/.agents/skills/release-openclaw-maintainer/SKILL.md b/.agents/skills/release-openclaw-maintainer/SKILL.md
index c59e66108eec..519d0281be09 100644
--- a/.agents/skills/release-openclaw-maintainer/SKILL.md
+++ b/.agents/skills/release-openclaw-maintainer/SKILL.md
@@ -237,13 +237,17 @@ Docker Gateway images. Treat
 on pinned current `main` as the exact command and validation contract.
 
 1. Check out the canonical `extended-stable/YYYY.M.33` branch after the
-   approved backport PR lands. Freeze its full 40-character SHA after verifying
-   the root and every publishable official plugin have the intended version.
-   Backport the complete current-main Docker release-channel change, including
-   its workflow, promoter, policy, shared release-version classifier, tests,
-   and workflow validation changes. Do not tag yet; tag-push workflows use
-   that code, which must not route `.33+` to regular stable aliases or fail
-   from a partial copy.
+   approved backport PR lands. Verify the root and every publishable official
+   plugin have the intended version, then generate and commit the complete
+   `## YYYY.M.P` `CHANGELOG.md` section before freezing its full 40-character
+   SHA. Unlike the regular Code-SHA flow, this npm-only candidate preflight
+   packages the frozen tree, so a matching non-empty changelog section is a
+   prerequisite, not post-validation release decoration. Backport the complete
+   current-main Docker release-channel change, including its workflow, promoter,
+   policy, shared release-version classifier, tests, and workflow validation
+   changes. Do not create the final tag yet; tag-push workflows use that code,
+   which must not route `.33+` to regular stable aliases or fail from a partial
+   copy.
 2. Dispatch `openclaw-npm-release.yml` from that canonical branch with the
    frozen SHA as `tag`, `preflight_only=true`, and
    `npm_dist_tag=extended-stable`. A full SHA is a validation-only candidate
@@ -254,9 +258,10 @@ on pinned current `main` as the exact command and validation contract.
    so trusted workflow code is pinned independently from the exact product
    target. Save the successful run ID and its exact `run_attempt` from
    `gh api repos/openclaw/openclaw/actions/runs/<run-id> --jq .run_attempt`.
-4. If either candidate gate fails or another backport is needed, commit it to
-   the canonical branch, freeze its new SHA, and rerun the affected gates. Do
-   not create, delete, or move a final `vYYYY.M.P` tag for candidate validation.
+4. If either candidate gate fails or another backport is needed, update the
+   canonical branch and its matching `CHANGELOG.md` section, freeze its new
+   SHA, and rerun the affected gates. Do not create, delete, or move a final
+   `vYYYY.M.P` tag for candidate validation.
 5. Only after the candidate gates are green, re-resolve the canonical branch
    tip and require it still equals the validated SHA. Create and push the
    signed final `vYYYY.M.P` tag at that SHA. Never move or delete a final
diff --git a/docs/reference/RELEASING.md b/docs/reference/RELEASING.md
index a901f5e8b055..0845d95fa689 100644
--- a/docs/reference/RELEASING.md
+++ b/docs/reference/RELEASING.md
@@ -58,10 +58,13 @@ already contain a strictly later calendar month's final version below patch
 month.
 
 On the exact extended-stable branch, bump the root package to `YYYY.M.P`, run
-`pnpm release:prep`, and verify every publishable plugin package has the
-same version. Commit and push all generated changes, then freeze and record the
-resulting full SHA. The workflows consume this prepared tree; they do not bump
-or synchronize versions for you. Do not create the final tag for a candidate.
+`pnpm release:prep`, and verify every publishable plugin package has the same
+version. Generate a complete `## YYYY.M.P` section in `CHANGELOG.md` with the
+required `### Highlights`, `### Changes`, and `### Fixes` headings, then commit
+and push all generated changes. The npm preflight packages that exact tree and
+rejects a missing or empty matching release section. Freeze and record the
+resulting full SHA; the workflows do not bump versions, synchronize packages,
+or create release notes for you. Do not create the final tag for a candidate.
 
 Before running candidate gates, backport the complete Docker release-channel
 change from current `main` as one tested unit. Its runtime files include
@@ -95,13 +98,13 @@ pins trusted workflow code while recording the exact product SHA and canonical
 branch context. Its stable validation profile is separate from the npm
 `extended-stable` dist-tag.
 
-If either candidate gate fails or another backport is needed, update the branch,
-freeze a new SHA, and rerun the affected candidate gates. Do not create, delete,
-or move a final tag during candidate validation. Once both gates are green,
-re-resolve the branch tip, require it still equals `RELEASE_SHA`, then create
-and push signed `vYYYY.M.P` at that SHA. A post-tag source change requires a
-new patch version and new candidate; final extended-stable tags are never moved
-or deleted.
+If either candidate gate fails or another backport is needed, update the branch
+and its matching changelog section, freeze a new SHA, and rerun the affected
+candidate gates. Do not create, delete, or move a final tag during candidate
+validation. Once both gates are green, re-resolve the branch tip, require it
+still equals `RELEASE_SHA`, then create and push signed `vYYYY.M.P` at that
+SHA. A post-tag source change requires a new patch version and new candidate;
+final extended-stable tags are never moved or deleted.
 
 Pushing the tag starts `Docker Release`, which publishes version-specific
 default, slim, browser, and architecture tags to both registries. It verifies their