* feat(agent-core): align model-facing prompts with actual tool behavior
A hunk-by-hunk accuracy pass over every model-visible prompt surface
(system.md, tool .md descriptions, zod describes, profile role prompts,
and injected reminder strings), with each claim verified against the
implementation and, where possible, empirically (ripgrep semantics).
Fix descriptions that drifted from the code:
- Grep `glob` matches against each file's absolute path, so
`src/**/*.ts` silently matches nothing — document the working forms
- Glob `path` accepts relative paths; results are files-only
- FetchURL no longer promises a content-type-to-mode mapping the
default provider does not honor
- cron: a pinned-date 5-field expression repeats yearly unless
`recurring: false`; drop a bench-only env knob from cron-list
- skill `args` expansion covers $NAME/$1/$ARGUMENTS and the trailing
ARGUMENTS: line; goal reminder no longer cites a nonexistent
developer-message channel
Disclose enforced-but-silent behavior:
- cron fires deliver only while the session is idle; expressions with
no fire within 5 years are rejected at create time
- VCS metadata directories are always excluded from Glob/Grep, even
with include_ignored; sensitive-file guard exemptions
(.env.example/.env.sample/.env.template, public SSH keys)
- large images may be downsampled while the <system> block reports
original dimensions; subagent summaries under the length floor are
sent back for expansion; background-disabled Agent calls are
rejected before launch; AGENTS.md beyond ~32 KB triggers a
performance warning (surfaced in the /init prompt)
Resolve cross-surface contradictions:
- AskUserQuestion background describe/envelope no longer teach polling
- AgentSwarm subagent_type documents that resume keeps original types
- bash.md scopes &&-chaining to dependent commands and steers
independent read-only commands to parallel calls
- the shared system prompt no longer names tools that read-only
subagent profiles lack
Add missing guidance:
- denied/rejected tool calls mean the user declined that action —
adjust, don't retry or route around (root agent)
- plan subagent now knows it is read-only; coder subagent knows its
final message is the entire handoff; explore subagent knows web
tools are in scope
- gh CLI routing for GitHub-hosted work; FetchURL login-wall note;
a dual-use content-safety boundary; scope discipline,
surrounding-idiom, and dependency-verification norms; file:line
citation convention; progress notes on long multi-phase tasks
* fix(agent-core): let the model fetch a background answer after the completion notice
In sessions with background persistence (any agent with a homedir), a
background question's answer is flushed to output.log and the completion
notification carries an <output-file> pointer, not the answer text. The
previous envelope wording ("use TaskOutput only to re-read the answer if
you missed the notification") gated the normal post-completion fetch
behind a missed-notification condition, so a model could acknowledge the
notice and continue without ever reading the user's answer.
Reword the envelope to state that the completion notice may carry a
pointer and to direct the model to read that file (or call TaskOutput
once) for the answer, while still forbidding polling before the user
responds. Align the background param describe the same way ("notified
automatically" rather than "the answer arrives", polling scoped to the
pending window).
* fix
|
||
|---|---|---|
| .. | ||
| cap-foreground-command-output.md | ||
| config.json | ||
| fix-search-sessions-horizontal-scroll.md | ||
| moonshot-tool-call-id-recovery.md | ||
| prompt-accuracy-pass.md | ||
| README.md | ||
| refresh-web-icons.md | ||
| sharpen-compaction-handoff-prompt.md | ||
Changesets
This repository uses changesets to manage npm package versions and releases.
Package Publishing Strategy
This repository uses an independent, manually-selected publishing strategy. When generating a changeset, only select the publishable packages that this change actually affects. The repository's .changeset/config.json already filters out internal workspace packages via ignore, so only the publishable packages listed below should appear in the pnpm changeset prompt.
Current publishable packages:
| Package | Directory | Description |
|---|---|---|
@moonshot-ai/kimi-code |
apps/kimi-code |
CLI / TUI application — provides the kimi command after install |
@moonshot-ai/kimi-code-sdk |
packages/node-sdk |
Public TypeScript SDK |
All other workspace packages are private internal packages, are not published to npm, and are excluded via ignore in .changeset/config.json:
@moonshot-ai/acp-adapter@moonshot-ai/agent-core@moonshot-ai/kaos@moonshot-ai/kimi-code-oauth@moonshot-ai/kimi-telemetry@moonshot-ai/kimi-web@moonshot-ai/kosong@moonshot-ai/migration-legacy@moonshot-ai/protocol@moonshot-ai/server@moonshot-ai/server-e2e@moonshot-ai/vis@moonshot-ai/vis-server@moonshot-ai/vis-webkimi-migration-legacy
Version impact from internal dependencies must be judged manually. The published artifacts for CLI and SDK bundle internal workspace packages into the artifact itself; runtime dependencies of published packages must not include any @moonshot-ai/* internal workspace packages.
The repository's .changeset/config.json sets updateInternalDependencies: "patch". Because internal packages are not published, you still need to manually select all affected publishable packages in the changeset — do not rely solely on automatic dependency bumps to express user-visible changes.
Example scenarios:
| Change | Changeset selection |
|---|---|
Only modifies TUI behavior in @moonshot-ai/kimi-code |
Add patch / minor / major to @moonshot-ai/kimi-code |
| Only modifies internal packages, no user-visible change in SDK / CLI | Usually no changeset needed |
| Internal package fix changes the CLI user experience | Add a changeset to @moonshot-ai/kimi-code describing the user-visible fix |
| Internal package adds a new capability exposed by the SDK | Add a changeset to @moonshot-ai/kimi-code-sdk |
| SDK behavior change affects CLI user experience | Add changesets to both @moonshot-ai/kimi-code-sdk and @moonshot-ai/kimi-code |
| Provider abstraction change affects SDK / CLI | Add changesets to the affected @moonshot-ai/kimi-code-sdk and/or @moonshot-ai/kimi-code |
| Test-only, internal refactor, docs, or private debug tooling changes | Usually no changeset needed |
Bundled official plugin change under plugins/ (e.g. kimi-datasource) |
No changeset — the plugin is versioned via its own kimi.plugin.json / plugins/marketplace.json and shipped through the marketplace CDN, not the npm package |
Prerequisite: NPM Trusted Publishing (OIDC)
This repository uses npm's Trusted Publishing (OIDC-based) for publishing — no NPM_TOKEN is required.
Configuration steps
- Open each publishable package's page on the npm website, e.g.
https://www.npmjs.com/package/@moonshot-ai/kimi-code. - Go to Settings -> Publishing access.
- Find Automate publishing with GitHub Actions or Add trusted publisher.
- Click Add a new trusted publisher.
Fill in the following:
| Field | Value |
|---|---|
| GitHub Organization | MoonshotAI |
| GitHub Repository | kimi-code |
| GitHub Workflow | release.yml |
| Environment | leave empty |
Each publishable package needs its Trusted Publisher configured once. The current GitHub Actions workflow lives at .github/workflows/release.yml and already has id-token: write configured.
Development Workflow
1. Implement the feature or fix
Complete code, tests, and documentation changes as usual. A changeset is required when the change affects user-visible behavior, public API, dependency ranges, or release artifacts of a publishable package.
2. Generate a changeset
From the repository root:
pnpm changeset
Follow the prompts to choose:
- Which publishable packages this change affects;
- The version bump level:
patch: bug fixes, small changes, follow-up dependency updates;minor: backward-compatible new features;major: breaking changes;
- A user-facing description of the change.
The command creates a .changeset/*.md file that must be committed alongside the code.
3. Commit the changeset
git add .changeset/
git commit -m "chore: add changeset for package release"
git push
Commit messages must follow Conventional Commit style. Do not include any author/agent identity in the commit message.
4. CI generates the release PR
Once the changeset file is merged into main, .github/workflows/release.yml uses changesets/action@v1 to create or update a release PR.
The release PR runs:
pnpm changeset version: bumps publishable package versions and updates changelogs;- Deletes the consumed
.changeset/*.mdfiles; - Uses the title
[CI]: Release packages.
5. Merge the release PR
Once the release PR is merged into main, the same workflow runs:
pnpm install --frozen-lockfilepnpm buildpnpm changeset publish
The packages are then published via npm Trusted Publishing, and a GitHub Release is created.
Manual Publishing (Not Recommended)
Only publish manually when CI is unavailable. Before publishing manually, make sure you are logged into npm locally and using the Node.js and pnpm versions required by the repository.
pnpm run version
pnpm run publish
The underlying changesets commands are:
pnpm changeset version
pnpm changeset publish
The root-level pnpm run publish first runs typecheck, lint, sherif, test, build, and package lint, then runs changeset publish.
Notes
- Every PR that affects publishable-package behavior or public API should include a corresponding changeset.
- Changes under
plugins/(the bundled official plugins such askimi-datasource) do not need a changeset: each plugin carries its own version inkimi.plugin.jsonandplugins/marketplace.jsonand is distributed via the marketplace CDN, separately from the@moonshot-ai/kimi-codenpm package. - Changeset files must be committed to the repository — release PRs are only triggered after they're merged.
- Release PRs require human review and merge; they will not publish automatically.
- Do not add release changesets for private internal packages; only select
@moonshot-ai/kimi-codeand@moonshot-ai/kimi-code-sdk. - If a change in an underlying internal package alters user-visible behavior or public API of a publishable package, add a changeset to the affected publishable package. For example, when a bug fixed in
@moonshot-ai/agent-coreresolves an issue CLI users encounter, add a changeset to@moonshot-ai/kimi-codedescribing the user-visible fix. @moonshot-ai/kimi-codeis the official CLI package name; after a global install it provides thekimicommand.- Make sure each publishable package on npm has a Trusted Publisher configured.