release
Execute the release workflow for Kimi CLI packages.
>_
Quick Installnpxskills add moonshotai/kimi-cli--skill releaseInstructions
Loading…
Execute the release workflow for Kimi CLI packages.
npxskills add moonshotai/kimi-cli--skill releaseLoading…
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.
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.
Fail fast — never paper over an error to keep the release moving. Stop and report back to the user when any of these happen:
uv sync fails or produces unexpected uv.lock churn beyond the version bump.gen-docs reports a doc inconsistency you cannot resolve.--no-verify or force-merge.Confirm new versions with the user. For each changed package, propose a new version and confirm before editing. Versioning policy:
0.Create the release branch. Name it bump-<package>-<new-version>. If multiple packages are being bumped together, use a single branch with a descriptive name.
Update version metadata and changelogs. For each changed package:
pyproject.toml.CHANGELOG.md, keeping the ## Unreleased header empty in place (do not rename it — add a new dated ## <version> (YYYY-MM-DD) section below it).breaking-changes.md in both languages if there are breaking changes.packages/kosong or packages/kaos, also update the root pyproject.toml pinned dependency (kosong[contrib]==<version> or pykaos==<version>) so root validation keeps passing.Sync the kimi-code wrapper when the root version changes. Bump packages/kimi-code/pyproject.toml version and its kimi-cli==<version> dependency to match the new root version.
Run uv sync to refresh the lockfile.
Update docs. Follow the gen-docs skill to make sure docs reflect the release.
Confirm with the user before opening the PR. Summarize the staged changes and ask the user to explicitly confirm:
pyproject.toml (changed package + packages/kimi-code if the root moved) reflects the version agreed in step 3.pyproject.toml pins (kosong[contrib]==<version>, pykaos==<version>) and packages/kimi-code's kimi-cli==<version> match the bumped versions.## Unreleased (Unreleased still present and empty), breaking-changes.md is updated in both languages if applicable, and gen-docs left no inconsistencies.Wait for explicit user approval before proceeding. If the user flags anything, fix it and re-confirm — do not push.
Open the PR. Commit all changes, push, and open a PR with gh. The PR description must follow this structure (see https://github.com/MoonshotAI/kimi-cli/pull/2225 for reference):
## Summary
- Bump <package> to <version>
- Move the current release notes under <version>
- (If applicable) Move breaking-change entries under <version>
- (If applicable) Any additional noteworthy changes (dependency pin updates, etc.)
## Validation
- uv run python scripts/check_version_tag.py --pyproject <pyproject> --expected-version <version>
- (For root releases) uv run python scripts/check_version_tag.py --pyproject packages/kimi-code/pyproject.toml --expected-version <version>
- uv run python scripts/check_kimi_dependency_versions.py --root-pyproject pyproject.toml --kosong-pyproject packages/kosong/pyproject.toml --pykaos-pyproject packages/kaos/pyproject.toml
- make check
## Post-merge
After this PR lands, create and push the release tag:
```sh
git tag <tag>
git push origin <tag>
Hand off the tag step. After merge, switch to main, pull latest, and tell the user the exact git tag command for the final release tag (pick the right tag pattern from the table above — e.g. git tag 1.43.0 for a root release, git tag kosong-0.54.0 for a kosong release). The user will run the tag and push tags themselves.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).