القائمة
Execute the release workflow for Kimi Code CLI packages.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/MoonshotAI/kimi-cli --skill releaseيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Generate changelog entries for code changes.
Sample plugin demonstrating the Skills + Tools model. Includes a Python tool (greeting) and a TypeScript tool (calculator).
针对 Kimi Code CLI 的新增或变更功能，规划并执行可重复的端到端冒烟测试。从 git diff 推断功能边界，读取相关文档和代码，设计测试 prompt，以 --print 非交互模式运行本地 CLI，检查进程退出码和 session 产物，总结预期与实际行为之间的差异。发现问题时自动启动多路并行探查以定位根因。
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | release |
| description | Execute the release workflow for Kimi Code CLI packages. |
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: is a thin wrapper and must stay version-synced with , so treat it as changed whenever the root package changes.
packages/kimi-codekimi-cliConfirm 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.
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.