release

Automates release workflow for Kimi Code CLI packages and their dependencies.

1|Updated Feb 19, 2026
One-click install
npx skills add https://github.com/Arist12/kimi-cli --skill release-arist12
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/Arist12/kimi-cli/tree/main/.agents/skills/release
Command: npx skills add https://github.com/Arist12/kimi-cli --skill release-arist12

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Executes and coordinates the release workflow for Kimi Code CLI packages, reducing manual coordination, version drift, and tagging errors across multiple components.

Core Features & Use Cases

  • Automates release orchestration across packages, sdks, and the root repository.
  • Synchronizes versions (e.g., kimi-code with kimi-cli), updates CHANGELOGs, and prepares breaking changes notes.
  • Creates a dedicated feature branch and opens a PR to surface release changes and guide post-merge steps.

Quick Start

Initiate the release workflow to automatically check for changes, update versions, and open a PR.

Frequently Asked Questions about release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate package release coordination across multiple components?

Automate package release coordination by reading AGENTS.md and .github/workflows/release*.yml, checking for package changes, updating versions, and opening a release PR. This workflow reduces manual coordination and version drift across packages, sdks, and the repository root.

How does version synchronization work between kimi-code and kimi-cli packages?

Version synchronization ensures packages/kimi-code stays version-synced with kimi-cli. When changes are detected, the release workflow confirms new versions with you and updates pyproject.toml and Cargo.toml if the root version changes.

What's the best way to publish updated versions and changelogs for a monorepo?

Publish updated versions and changelogs by creating a dedicated feature branch and opening a PR. The workflow updates CHANGELOG.md and breaking-changes.md to surface release changes and guide post-merge steps for the changed packages.

Can I use this release workflow if my project only has packages at the root level?

Yes, the release workflow checks each package under packages/, sdks/, and the repo root for changes since the last release. If only root-level packages are modified, it updates the necessary files and opens a PR for the release.

Why do I need to confirm new package versions before opening a release PR?

Confirming new package versions before opening a release PR prevents unintended version bumps and tagging errors. The workflow checks for changes across components and asks you to verify the new versions before updating configuration files.

What files need to be updated when the root package version changes?

When the root package version changes, the release workflow updates pyproject.toml and Cargo.toml, along with CHANGELOG.md and breaking-changes.md. These updates are pushed to a feature branch before the release PR is opened.