Generate Changesets

The only user-facing published package is the CLI: @moonshot-ai/kimi-code. All other @moonshot-ai/* packages (sdk, kosong, kaos, oauth, telemetry, and so on) are internal.

1. Whether to Write

Rule of thumb: if users cannot perceive the change, write no changeset. A changeset is a user-facing changelog entry, not a shipping gate — internal changes merged to main ship with the next release anyway, so skipping loses nothing.

Do not write:

• Docs-only or tests-only changes that never enter the shipped artifact.
• Changes internal to core/server packages — architecture, protocols, refactors, config/journal/wire mechanics — unless they fix a bug users care about.
• When you are unsure whether users can perceive a change, ask first.

Do write: user-perceivable new features or behavior changes, and internal-package changes that fix a user-useful bug or change CLI output/behavior (list @moonshot-ai/kimi-code for those).

2. What to Write

Create a short kebab-case file under .changeset/: