Pre-Changelog

Preview the user-facing Chinese changelog of an open kimi-code release PR before it is merged. Read-only: this skill writes no files and commits nothing.

This skill reuses sync-changelog's strip / classify / translate rules. Read sync-changelog first; only the data source (release PR diff instead of a published CHANGELOG.md) and the output (preview instead of docs files) differ.

Workflow

1. Locate the release PR

gh pr list --state open --search "ci: release packages in:title" \
  --json number,title,url,headRefName,baseRefName

Pick the one with headRefName: changeset-release/main; record number, url as <RELEASE>. If none is open, nothing to preview — stop.

2. Read the pre-generated CLI changelog block

changesets already pre-generates apps/kimi-code/CHANGELOG.md inside the release PR. Extract the new version block from the diff:

gh api repos/MoonshotAI/kimi-code/pulls/<RELEASE>/files \
  --jq '.[] | select(.filename=="apps/kimi-code/CHANGELOG.md") | .patch'

Take the added lines (+) from the top ## <version> down to (but not including) the next ## . That is the version block to preview.

If the CLI changelog is not in the diff (for example an SDK-only release), stop and tell the user — there is no user-facing CLI changelog to preview.

3. Render the Chinese preview (reuse sync-changelog)

Process the version block exactly as sync-changelog does for the docs site, but only in memory:

• Strip (sync-changelog step 3): drop the H1, the ### Patch Changes / ### Minor Changes / ### Major Changes subheadings, PR links, and commit-hash links; keep only each entry's body text. The Thanks [@user](...)! credit (including the multi-author form) must be removed every time. Within each entry, drop SDK-only and provider-internal sentences (SDK capability mapping / API exposure, provider wire-format mechanics, internal XML markers, hook/event payload mechanics such as what an event reports or carries) and keep only the user-facing effect and required constraints.
• Merge and deduplicate (sync-changelog step 4): merge micro-tweaks to the same surface into one higher-level entry; when three or more fixes target the same UI area or the same class of problem, merge them into one higher-level fix entry (do not merge broad or genuinely distinct fixes); and drop a server/API entry that only backs a web feature already listed.
• Collapse low-signal entries (sync-changelog step 4): keep standalone only entries that pass both gates — the reader-action test (the reader must do or re-evaluate something) and the channel test (the product cannot push it into the user's path: hidden controls, habit invalidations, capabilities users would not know to seek — a control merely sitting in the UI is not surfacing, users do not explore). Polish keeps only must-react items; experiences the product shows at the moment of need (recovery cards, post-install guidance) fold. Fixes keep only behavior-change entries (readers must update a habit, config, or workaround); loud failures fold (the fix itself notifies the victim), and silent past damage folds too — the changelog does not repair the past, and a notice that names no locatable instance and no realistic action is noise, not diligence. Section sizes follow density defaults (about 2 polish, 3 fixes) that yield to genuinely qualifying entries — flag the overflow for the reviewer instead of folding to hit the number. Fold everything else into one catch-all line placed last under 修复 — 修复了一些已知问题。 (or 修复了一些已知问题，并做了若干细节优化。 when non-fix entries were also collapsed; when nothing folded is a fix, place it under 优化 instead as 做了若干细节优化和内部改进。), followed by a separate pointer sentence: 更详细的变更记录见 [GitHub](https://github.com/MoonshotAI/kimi-code/blob/main/apps/kimi-code/CHANGELOG.md)。 (file link, no version anchor; before the release PR merges, the target does not yet contain this version's block — expected for a preview).
• Classify (sync-changelog step 4): bucket into Features / Bug Fixes / Polish / Refactors / Other; order within each section by reader value (in Polish, user-visible improvements before protocol/internal adjustments).
• Translate (sync-changelog step 6): translate entry bodies to Chinese; keep one sentence per entry with a parallel rhythm within a section; section headings become 新功能 / 修复 / 优化 / 重构 / 其他.

If an upstream entry is not in English, flag it and stop (changeset entries must be English).

4. Output

Print the preview directly. Use <version>（预览） as the heading because the version is not released yet. Write 无 for empty sections. Do not write any file.

After the preview block, append a reviewer-only section titled ### 审稿参考（不进入文档）: list every entry folded into the catch-all (short English title, one line each), note any section that exceeds the density defaults, and flag borderline calls for the reviewer to confirm. This breakdown is how reviewers see what was folded — before merge, the catch-all pointer's target does not yet contain the version's block. Never write this section into the docs pages.

The preview is pasted into chat tools (for example Lark), where relative docs links do not resolve. Rewrite every docs link to its absolute published URL: map ../<path>.md[#anchor] to https://moonshotai.github.io/kimi-code/zh/<path>.html[#anchor] — for example ../configuration/config-files.md#loop-control → https://moonshotai.github.io/kimi-code/zh/configuration/config-files.html#loop-control. Never emit raw relative paths, and never wrap a link in backticks; code-style the link text inside the brackets instead (loop_control).

发版 PR: <url>

## <version>（预览）

### 新功能
- ...

### 修复
- ...

Rules

• Read-only. Never write CHANGELOG.md, docs files, or commit anything.
• Classification, ordering, and translation follow sync-changelog exactly — do not reword or reclassify beyond what it specifies.
• If the release PR has no CLI changelog diff, report it and stop.