Release process for Kimi Code CLI packages. Tags are pushed without a v prefix and follow one of these patterns (matched by .github/workflows/release-*.yml):

Tag pattern	Releases
`1.42.0` (numeric)	`kimi-cli` (root) + `kimi-code` wrapper, released together — versions must stay aligned
`kosong-0.53.0`	`packages/kosong`
`pykaos-0.9.0`	`packages/kaos` (PyPI name `pykaos`)
`kimi-sdk-0.3.0`	`sdks/kimi-sdk`

The Rust implementation (kagent) lives in a separate repository and is not released from here.

Steps

Understand the automation. Read AGENTS.md and .github/workflows/release*.yml so you know what each release workflow expects before changing any versions.
Detect changed packages. Check each release unit under packages/, sdks/, and the repo root for changes since its last release tag. Use path-scoped diffs for subpackages so unrelated repo changes do not trigger a package release, e.g. git diff kosong-0.53.0..HEAD -- packages/kosong, git diff pykaos-0.9.0..HEAD -- packages/kaos, and git diff kimi-sdk-0.2.1..HEAD -- sdks/kimi-sdk. If nothing changed anywhere, stop and report that there is nothing to release. Note: packages/kimi-code is a thin wrapper and must stay version-synced with kimi-cli, so treat it as changed whenever the root package changes.