| name | release-lithe |
| description | Prepare and validate stable Lithe release notes and publishing workflows. Use when drafting docs/releases files, cutting a stable version, publishing a GitHub Release, or changing stable release automation. |
Release Lithe
Apply this Skill after develop-lithe for stable releases. Preview releases
keep their existing workflow unless the task explicitly includes them.
Prepare the release notes first
- Create
docs/releases/v<version>.md and commit it before creating the tag or
manually dispatching either stable release workflow.
- Derive the content from the commits, pull requests, tests, packaging changes,
and known limitations between the previous stable tag and the target commit.
Do not invent features, compatibility claims, download assets, or fixes.
- Treat the release notes as a required release artifact. A missing or empty
file blocks the release; never fall back to GitHub-generated notes.
- Keep user-facing language focused on outcomes. Do not publish a raw commit or
pull-request list as the release description.
Use the bilingual structure
Write Simplified Chinese first and English second, separated by ---. Keep the
two sections equivalent in meaning. Use these literal required headings and
this order:
## 中文, a short release summary, ### 下载, and ### 重点更新.- Optional product-area groupings when they make the changes easier to scan.
### 升级说明 and ### 兼容性与已知问题.- A comparison link from the previous stable tag to the new tag.
## English, a short release summary, ### Downloads, and ### Highlights.- English counterparts for any optional product-area groupings.
- and .
