{"owner":"MoonshotAI","repo":"kimi-code","hasSkills":true,"totalSkillsCount":202,"totalTokensCount":86748,"categories":["anthropic-skill","root-instruction","claude-rule","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"kimi-code":{"command":"npx","args":["-y","@modelcontextprotocol/server-kimi-code"]}}},"found":[".agents/skills/review-pr/SKILL.md",".agents/skills/gen-docs/SKILL.md",".agents/skills/pre-changelog/SKILL.md",".agents/skills/translate-docs/SKILL.md",".agents/skills/gen-changesets/SKILL.md",".agents/skills/sync-changelog/SKILL.md","plugins/official/kimi-datasource/SKILL.md",".agents/skills/write-tui/SKILL.md","plugins/official/kimi-webbridge/skills/kimi-webbridge/SKILL.md",".agents/skills/write-pr/SKILL.md","packages/agent-core-v2/src/features/skill/tools/skill.md","packages/migration-legacy/test/fixtures/golden/.kimi/skills/golden-skill/SKILL.md","packages/agent-core-v2/src/features/skill/catalog/builtin/sub-skill/consolidate/SKILL.md","packages/agent-core-v2/src/features/skill/catalog/builtin/sub-skill/review/SKILL.md","AGENTS.md","CLAUDE.md","docs/AGENTS.md","plugins/marketplace.json","packages/acp-server/CHANGELOG.md","packages/acp-server/package.json","packages/acp-server/tsconfig.json","packages/agent-core-v2/CHANGELOG.md","packages/agent-core-v2/package.json","packages/agent-core-v2/tsconfig.contract.json","packages/agent-core-v2/tsconfig.json","packages/kap-server/CHANGELOG.md","packages/kap-server/package.json","packages/kap-server/tsconfig.dev.json","packages/kap-server/tsconfig.json","packages/klient/AGENTS.md","packages/klient/CHANGELOG.md","packages/klient/README.md","packages/klient/package.json","packages/klient/tsconfig.examples.json","packages/klient/tsconfig.json","packages/kosong/CHANGELOG.md","packages/kosong/README.md","packages/kosong/package.json","packages/kosong/tsconfig.json","packages/kosong/tsconfig.type-negative.json","packages/migration-legacy/CHANGELOG.md","packages/migration-legacy/package.json","packages/migration-legacy/tsconfig.json","packages/minidb/AGENTS.md","packages/minidb/CHANGELOG.md","packages/minidb/DESIGN_NOTES.md","packages/minidb/README.md","packages/minidb/package.json","packages/minidb/tsconfig.json","packages/node-sdk/CHANGELOG.md","packages/node-sdk/README.md","packages/node-sdk/api-extractor.json","packages/node-sdk/package.json","packages/node-sdk/tsconfig.api-extractor.json","packages/node-sdk/tsconfig.dts.json","packages/node-sdk/tsconfig.json","packages/oauth/CHANGELOG.md","packages/oauth/README.md","packages/oauth/package.json","packages/oauth/tsconfig.json","packages/pi-tui/AGENTS.md","packages/pi-tui/CHANGELOG.md","packages/pi-tui/README.md","packages/pi-tui/UPSTREAM.md","packages/pi-tui/package.json","packages/pi-tui/tsconfig.json","packages/product/CHANGELOG.md","packages/product/package.json","packages/product/tsconfig.json","packages/remote-control/CHANGELOG.md","packages/remote-control/package.json","packages/remote-control/tsconfig.json","packages/telemetry/CHANGELOG.md","packages/telemetry/README.md","packages/telemetry/package.json","packages/telemetry/tsconfig.json","packages/transcript/CHANGELOG.md","packages/transcript/package.json","packages/transcript/tsconfig.json","packages/tree-sitter-bash/README.md","packages/tree-sitter-bash/package.json","packages/tree-sitter-bash/tsconfig.json",".agents/skills/review-pr/surfaces.md",".agents/skills/write-tui/DESIGN.md","plugins/official/kimi-datasource/CHANGELOG.md","plugins/official/kimi-datasource/kimi.plugin.json","plugins/official/kimi-datasource/watchlist.json","plugins/official/kimi-webbridge/kimi.plugin.json","packages/agent-core-v2/docs/en/event-name.md","packages/agent-core-v2/docs/en/llm.md","packages/agent-core-v2/docs/zh/event-name.md","packages/agent-core-v2/docs/zh/llm.md","packages/agent-core-v2/src/human/package.json","packages/pi-tui/native/darwin/README.md","packages/pi-tui/native/linux/README.md","packages/pi-tui/native/win32/README.md","packages/tree-sitter-bash/test/fixtures/README.md","packages/agent-core-v2/src/agent/contextMemory/compaction-summary-prefix.md","packages/agent-core-v2/src/agent/fullCompaction/compaction-instruction.md","packages/agent-core-v2/src/agent/fullCompaction/context-recovery-footer.md","packages/agent-core-v2/src/app/agentProfileCatalog/system.md","packages/agent-core-v2/src/features/tower/tower-worker-overlay.md","packages/agent-core-v2/src/human/compaction/compaction-instruction.md","packages/agent-core-v2/src/human/compaction/compaction-summary-prefix.md","packages/agent-core-v2/src/human/llm/AGENTS.md","packages/agent-core-v2/src/human/media/read-media.md","packages/agent-core-v2/src/human/todo/todo-list-write-reminder.md","packages/agent-core-v2/src/human/todo/todo-list.md","packages/agent-core-v2/src/human/tool/wait-for.md","packages/migration-legacy/test/fixtures/archived/state.json","packages/migration-legacy/test/fixtures/broken-state-json/state.json","packages/migration-legacy/test/fixtures/large-100msgs/state.json","packages/migration-legacy/test/fixtures/legacy-protocol-1.3/state.json","packages/migration-legacy/test/fixtures/recent-protocol-1.10/state.json","packages/migration-legacy/test/fixtures/tiny-hello-world/state.json","packages/migration-legacy/test/fixtures/title-only/state.json","packages/migration-legacy/test/fixtures/with-subagent-collapsed/state.json","packages/migration-legacy/test/fixtures/with-thinking/state.json","packages/migration-legacy/test/fixtures/with-tool-calls/state.json","packages/tree-sitter-bash/test/fixtures/corpus/README.md","packages/agent-core-v2/src/agent/permissionMode/injection/permission-mode-auto-enter-reminder.md","packages/agent-core-v2/src/agent/permissionMode/injection/permission-mode-auto-exit-reminder.md","packages/agent-core-v2/src/agent/tools/agent/agent-background-disabled.md","packages/agent-core-v2/src/agent/tools/agent/agent-background-enabled.md","packages/agent-core-v2/src/agent/tools/agent/agent-fork.md","packages/agent-core-v2/src/agent/tools/agent/agent.md","packages/agent-core-v2/src/agent/tools/ask-user-question/ask-user.md","packages/agent-core-v2/src/agent/tools/edit/edit.md","packages/agent-core-v2/src/agent/tools/fetch-url/fetch-url.md","packages/agent-core-v2/src/agent/tools/read-media-file/read-media.md","packages/agent-core-v2/src/agent/tools/web-search/web-search.md","packages/agent-core-v2/src/features/goal/injection/goal-active-reminder.md","packages/agent-core-v2/src/features/goal/injection/goal-blocked-reminder.md","packages/agent-core-v2/src/features/goal/injection/goal-paused-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-exit-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-full-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-inline-full-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-inline-reentry-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-inline-sparse-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-reentry-reminder.md","packages/agent-core-v2/src/features/plan/injection/plan-mode-sparse-reminder.md","packages/agent-core-v2/src/features/sessionInit/profile/init.md","packages/agent-core-v2/src/features/swarm/agent/enter-reminder.md","packages/agent-core-v2/src/features/swarm/agent/exit-reminder.md","packages/agent-core-v2/src/features/tower/injection/tower-mode-exit-reminder.md","packages/agent-core-v2/src/features/tower/injection/tower-mode-full-reminder.md","packages/agent-core-v2/src/features/tower/injection/tower-mode-sparse-reminder.md","packages/agent-core-v2/src/session/agentLifecycle/profile/explore-overlay.md","packages/migration-legacy/test/fixtures/golden/.kimi-historical-config/config.json","packages/migration-legacy/test/fixtures/golden/.kimi/kimi.json","packages/migration-legacy/test/fixtures/golden/.kimi/mcp.json","packages/migration-legacy/test/fixtures/multi-workdir/.kimi/kimi.json","plugins/official/kimi-webbridge/skills/kimi-webbridge/references/operations.md","packages/agent-core-v2/src/agent/tools/os/bash/bash.md","packages/agent-core-v2/src/agent/tools/os/glob/glob.md","packages/agent-core-v2/src/agent/tools/os/grep/grep.md","packages/agent-core-v2/src/agent/tools/os/read/read.md","packages/agent-core-v2/src/agent/tools/os/write/write.md","packages/agent-core-v2/src/agent/tools/task/task-list/task-list.md","packages/agent-core-v2/src/agent/tools/task/task-output/task-output.md","packages/agent-core-v2/src/agent/tools/task/task-stop/task-stop.md","packages/agent-core-v2/src/agent/tools/task/task-wait/task-wait.md","packages/agent-core-v2/src/features/cron/tools/cron-create/cron-create.md","packages/agent-core-v2/src/features/cron/tools/cron-delete/cron-delete.md","packages/agent-core-v2/src/features/cron/tools/cron-list/cron-list.md","packages/agent-core-v2/src/features/goal/tools/create-goal/create-goal.md","packages/agent-core-v2/src/features/goal/tools/get-goal/get-goal.md","packages/agent-core-v2/src/features/goal/tools/set-goal-budget/set-goal-budget.md","packages/agent-core-v2/src/features/goal/tools/update-goal/update-goal.md","packages/agent-core-v2/src/features/notify/tools/notify-user/notify-user.md","packages/agent-core-v2/src/features/plan/tools/exit-plan-mode/exit-plan-mode.md","packages/agent-core-v2/src/features/skill/catalog/builtin/check-kimi-code-docs.md","packages/agent-core-v2/src/features/skill/catalog/builtin/custom-theme.md","packages/agent-core-v2/src/features/skill/catalog/builtin/import-from-cc-codex.md","packages/agent-core-v2/src/features/skill/catalog/builtin/mcp-config.md","packages/agent-core-v2/src/features/skill/catalog/builtin/update-config.md","packages/agent-core-v2/src/features/skill/catalog/builtin/write-goal.md","packages/agent-core-v2/src/features/swarm/tools/agent-swarm/agent-swarm-fork.md","packages/agent-core-v2/src/features/swarm/tools/agent-swarm/agent-swarm.md","packages/agent-core-v2/src/features/todo/tools/todo-list/todo-list.md","packages/agent-core-v2/src/features/tower/tools/complete/complete.md","packages/agent-core-v2/src/features/tower/tools/finding/finding.md","packages/agent-core-v2/src/features/tower/tools/inbox/inbox.md","packages/agent-core-v2/src/features/tower/tools/init/init.md","packages/agent-core-v2/src/features/tower/tools/merge/merge.md","packages/agent-core-v2/src/features/tower/tools/mission/mission.md","packages/agent-core-v2/src/features/tower/tools/plan/plan.md","packages/agent-core-v2/src/features/tower/tools/rebase/rebase.md","packages/agent-core-v2/src/features/tower/tools/review/review.md","packages/agent-core-v2/src/features/tower/tools/send/send.md","packages/agent-core-v2/src/features/tower/tools/spawn/spawn.md","packages/agent-core-v2/src/features/tower/tools/status/status.md","packages/agent-core-v2/src/features/tower/tools/teardown/teardown.md","packages/migration-legacy/test/fixtures/golden/.kimi/credentials/kimi-code.json","packages/migration-legacy/test/fixtures/golden/.kimi/sessions/c1c0997494d4df46ac89f99f813c077c/11111111-aaaa-4bbb-8ccc-111111111111/state.json","packages/migration-legacy/test/fixtures/golden/.kimi/sessions/c1c0997494d4df46ac89f99f813c077c/22222222-aaaa-4bbb-8ccc-222222222222/metadata.json","packages/migration-legacy/test/fixtures/golden/.kimi/sessions/c1c0997494d4df46ac89f99f813c077c/22222222-aaaa-4bbb-8ccc-222222222222/state.json","packages/migration-legacy/test/fixtures/golden/.kimi/sessions/c1c0997494d4df46ac89f99f813c077c/33333333-aaaa-4bbb-8ccc-333333333333/state.json","packages/migration-legacy/test/fixtures/golden/.kimi/sessions/ssh_cc0fc5445bfc0662b9c89cf7c6896ebb/55555555-aaaa-4bbb-8ccc-555555555555/state.json","packages/migration-legacy/test/fixtures/multi-workdir/.kimi/sessions/73d3cf4d1cf337adf57d6732b8be2205/uuid-a1/state.json","packages/migration-legacy/test/fixtures/multi-workdir/.kimi/sessions/73d3cf4d1cf337adf57d6732b8be2205/uuid-a2/state.json","packages/migration-legacy/test/fixtures/multi-workdir/.kimi/sessions/kaos-foo_caaf674614e26c6365945408f85c9c9a/uuid-c1/state.json"],"skills":{".agents/skills/review-pr/SKILL.md":"---\nname: review-pr\ndescription: 在 kimi-code 仓库里 review 一个 PR 时使用：按 PR 模板逐节核对描述与 diff，并单独做一轮\"回归与用户影响\"评审，给出影响等级与评审摘要，评审摘要用用户当前使用的语言。\ndisable-model-invocation: true\n---\n\n# Review PR\n\n这个仓库过去的回归大多不是逻辑错误，而是\"改动相对于自身意图是对的，但悄悄改掉了某个现有人群依赖的行为\"：方言分支收窄、默认值翻转、删 system prompt 句子、重构或移植时丢掉旧路径的功能、修复引入启动时序变化。通用 review 会把这类\"有意的功能变更\"排除在 bug 之外，所以这里把它单列成一轮。\n\n评审判据只有一条：**改动前能工作的任何输入（配置键、环境变量、命令行参数、provider 响应形态、旧版本写的会话数据、客户端请求、hook 载荷）改动后必须行为不变，除非 PR 明确声明了这个变化并给出了退路。**\n\n## 工作流\n\n1. 拉 PR 元数据与描述：\n\n ```bash\n gh pr view --json title,body,url,files,additions,deletions,baseRefName,headRefName\n ```\n\n2. 读完整 diff（大 PR 按文件分批读）：\n\n ```bash\n gh pr diff \n ```\n\n3. 读足够的周边代码来验证描述里的每个断言。只看 diff 看不出\"改动前谁走到这个分支\"。\n\n4. **第一遍：定性。** 判断改动类型，决定第三遍的深度，见\"第一遍：定性\"。\n\n5. **第二遍：按模板逐节核对。** 见\"模板逐节核对\"。\n\n6. **第三遍：回归与用户影响。** 尽量用一个独立子 agent 跑：只给它 PR 号、base 与 head、两三句改动简介和 `surfaces.md` 的路径，不给它作者关于影响范围的结论，让它先从 diff 和代码独立列清单，回来后再与作者填的表对比。没有子 agent 能力时自己按同样顺序做：先列清单，再读作者的表。见\"第三遍：回归与用户影响\"。\n\n7. 用用户当前使用的语言写评审摘要，格式见\"输出\"。\n\n## 第一遍：定性\n\n| 改动类型 | 第三遍深度 |\n|---|---|\n| 纯内部重构、测试、文档、测试 CI | 只需给出\"没有可观测变化\"的证据：哪些分支、默认值、契约文件没动 |\n| 发布与打包：release、native 构建、VS Code 发布工作流，打包脚本，web 产物同步 | 全做，人群按安装方式与平台分：npm 包、各平台 native 二进制、VS Code 市场、内置 web 产物 |\n| 新增功能，不动既有路径 | 只查新分支是否抢走了既有输入：新增条件是否排在旧条件之前 |\n| 行为变更、默认值翻转、校验或权限收紧或放宽 | 全做 |\n| prompt 文本变更：system prompt、工具描述、提醒、overlay、内置 skill | 全做，且每一句改动单独成行 |\n| 移植、替换旧路径、大重构：v1 到 v2、runtime binding、协议替换 | 全做，并要求作者给出旧路径功能清单 |\n| 协议、磁盘格式、SDK 导出、hook 载荷、命令行契约变化 | 全做，并点名仓库外的消费方 |\n| 修复类改动改了启动顺序、生命周期、异步时序 | 全做，重点看谁依赖原来的顺序 |\n\n一个 PR 可以同时属于多类，按最重的那类处理。\n\n## 第三遍：回归与用户影响\n\n### 1. 行为变化清单\n\n列出 diff 改变的每一个可观测行为，包括作者说\"不变\"的和作者认为\"内部\"的。内部包会打进 CLI 发布包，\"内部\"不等于用户无感。\n\n每一行记录：行为、变化前、变化后、变化类型（新增 / 修改 / 删除 / 默认翻转 / 收紧 / 放宽）、证据（改动前后各一个 `file:line`，一侧不存在时给可达路径）。\n\n读法：\n\n- 对每个被删除或被收窄的分支、条件、默认值、句子，问\"改动前谁走到这里，改动后他们去哪了\"。\n- 对每个新增的分支或条件，问\"哪些既有输入现在会先命中新分支\"。#3492 的回归就是这样产生的：数组字段存在时不再读字符串字段，而 OpenRouter 形态的网关两者同时发。\n- 测试里\"把旧断言改成新行为\"的改动是行为变化的直接证据，逐条对应到清单。\n- 先看 diff 文件列表有没有命中 `surfaces.md` 的\"触发线索\"。命中的 surface 必须在清单里有对应行，否则就是漏项。\n\n### 2. 受影响人群\n\n每一行对应到 `surfaces.md` 里的具体人群，写出人群名字和\"这个人群存在\"的证据：文档页、issue、配置示例、provider 载荷形态。找不到人群的，不进 finding，进\"待作者确认\"。\n\n### 3. 影响等级\n\n等级只由改动的事实决定，不看 changeset、文档、测试这些补救状态。三步判定：\n\n1. 数据丢失、安全边界放宽、老数据不可读、某人群的功能整体不可用：直接 L3。\n2. 否则，可感知且有一键退路（config、env、flag）：L1；可感知且无退路，旧行为不可恢复：L2；无可观测变化：L0。\n3. 静默升级：用户提供的输入（配置、环境变量、数据、请求字段）被忽略或丢弃，且没有任何错误信号，用户无法自行发现：升一级，最高 L3。行为公开地变了、用户能在输出里看到的，不算静默。\n\n广度三档，必须写出人群名字：全体用户 / 某类配置或平台人群 / 边缘环境。\n\n每一行单独定级，PR 的等级取最高。静默升级的理由：没有信号就没有上报，回归会一直存活到有人偶然发现。\n\n### 4. 补救核对\n\n固定四问，逐条回答有 / 无 / 不适用，并给出证据：\n\n- 退路开关：有没有 config、env 或 flag 能恢复旧行为。\n- changeset：有没有点明用户**失去了什么**，而不只是新默认是什么；没有退路时是否明说旧行为不可恢复。\n- 老数据与老客户端：旧版本写的会话、迁移来的数据、上一版发布的客户端（desktop、web、VS Code、ACP）是否仍然可用；回滚到上一版是否安全。\n- guard 测试：有没有一条测试把**未被改动的人群**的旧行为钉住。\n\n再加一问：`docs/en` 与 `docs/zh` 里对这个 surface 的承诺是否同步更新。\n\n### 等级对应的处理要求\n\n- L3：建议阻塞。必须补 guard 测试，并提供退路、flag 门控或迁移，缺一不可合。\n- L2：需要维护者在 PR 里显式拍板；changeset 必须写明失去的行为；文档同步。\n- L1：核对 changeset 与文档即可。\n- L0：一句话说明为什么是 L0，给出证据。\n\n### finding 与\"待作者确认\"的界线\n\n- finding 必须同时有：改动前后各一处 `file:line` 证据，和一个具名人群及其存在证据。两者缺一，降级为\"待作者确认\"。新增整个文件或删除整段实现时一侧天然为空，这时给存在的那一侧加上受影响可达路径的 `file:line` 即可。\n- \"待作者确认\"最多 5 条，按可能的影响等级排序，多出来的只报数量。\n- 不要报：PR 之前就存在的问题（严重的单独一句\"顺带发现\"）、lint 和类型检查会抓的问题、风格问题。\n- 不要把这些当成\"无影响\"的证据：作者说\"不变\"、没有测试引用被删的句子、改动只在内部包。\n\n## 模板逐节核对\n\n输出为中文时节名用下表的译名，其他语言沿用模板原文的节名：\n\n| English | 中文 |\n|---------|------|\n| Requirement or Bug | 需求或 Bug |\n| Bug Reproduction Steps | Bug 复现步骤 |\n| Root Cause | 根本原因 |\n| Code Changes | 代码变更 |\n| Behavior Changes and Affected Users | 行为变化与受影响人群 |\n| Checklist | 检查清单 |\n\n旧 PR 若仍用 `Impact Scope` 这一节，按\"行为变化与受影响人群\"的标准核对。\n\n### 需求或 Bug\n\n- 关联的 issue 是否有效、相关？\n- 没有 issue 时，需求是否用一两句话说清楚了？\n\n### Bug 复现步骤\n\n- bug 类 PR：步骤是否清晰、可复现？\n- 按步骤能否在 base 分支上确认 bug 存在？\n\n### 根本原因\n\n- bug 类 PR：根因解释是否令人信服？\n- 描述的根因与 diff 是否一致？\n- 是根本修复还是绕过，是否说清楚了？\n\n### 代码变更\n\n- 描述与实际 diff 是否一致？\n- 可视化大纲（diff 块、调用树、文件树）是否准确、有帮助？\n- 方案是否合理？有没有更简单的替代？\n- 有没有作者漏掉的边界情况？\n\n### 行为变化与受影响人群\n\n- 把第三遍独立列出的清单与作者填的表逐行对比：作者漏列的行为就是 finding；作者写了但你没找到证据的，进\"待作者确认\"。\n- 人群是否具名，还是只写了\"部分用户\"？\n- 写了 `None` 的，证据是否成立？\n- 受影响模块与测试覆盖是否与 diff 文件列表一致？有没有带风险的未测路径？\n\n### 检查清单\n\n- 适用的项是否都勾了？\n- 标为\"不需要\"的项，你是否同意？\n\n## 输出\n\n用用户当前使用的语言，按下面的顺序，示例为中文：\n\n```markdown\n## 结论\n一句话：可合 / 需修改 / 建议阻塞。附 PR 影响等级与改动类型。\n\n## 回归与用户影响\n- 改动类型：…\n- 影响等级：Lx（广度：…；是否静默：…）\n\n| 行为 | 变化前 | 变化后 | 受影响人群 | 证据 | 等级 | 退路 |\n|---|---|---|---|---|---|---|\n\n补救核对：\n- 退路开关：…\n- changeset 是否点明失去的行为：…\n- 老数据与老客户端：…\n- guard 测试：…\n- 文档：…\n\n待作者确认（最多 5 条）：\n1. …\n\n## 模板逐节核对\n逐节说明是否填写充分，指出缺失、不准确、与 diff 不一致之处。\n\n## 需要修改的项\n可执行的列表；没有则写\"无\"。\n```\n\n## 复盘回填\n\n每次线上回归复盘后，把新发现的人群或触发线索补进 `surfaces.md`，并在它的\"历史案例\"里加一行。清单不更新就会过时。\n",".agents/skills/gen-docs/SKILL.md":"---\nname: gen-docs\ndescription: Update Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience.\n---\n\n# Gen Docs\n\n## Overview\n\nThis repository maintains bilingual user documentation under `docs/`. `docs/en/` and `docs/zh/` are mirrored pairs for most pages; update both in the same change. **Changelog is the exception** — English is the source, and Chinese is translated from English.\n\nUse this skill to update the corresponding documentation whenever the codebase has changes that affect product behavior or user experience.\n\nFor a **full pre-release audit** of all pages (detecting hallucinations and coverage gaps), use the `audit-docs` skill instead.\n\n## Prerequisites\n\nThis skill depends on the following being in place. If any are missing, stop and report to the user before continuing:\n\n- `docs/` directory with `docs/zh/`, `docs/en/`, and `docs/.vitepress/config.ts` set up (VitePress site).\n- `docs/AGENTS.md` style guide — defines source-of-truth rules, terminology table, typography, and writing style.\n- `docs/scripts/sync-changelog.mjs` — auto-syncs root `CHANGELOG.md` to `docs/en/release-notes/changelog.md`.\n- `translate-docs` skill in `.agents/skills/` — handles bilingual synchronization.\n\n## Workflow\n\n1. **Inspect changes**\n\n - `git log main..HEAD --oneline` — commits on the current branch\n - `git diff main..HEAD --stat` — file-level scope\n - `ls .changeset/*.md` (excluding `README.md`) — pending changeset entries\n - Read `CHANGELOG.md` and any subpackage `packages/*/CHANGELOG.md` for already-recorded entries.\n\n2. **Understand user-facing impact**\n\n For each change, read the actual implementation when needed; **do not infer behavior from commit messages or PR titles alone**. Skip:\n\n - Internal refactors with no externally visible behavior change\n - Tests, CI, type-only changes\n - Tooling / build-system changes that do not change how users invoke the CLI\n\n If after the scan you conclude there is no user-facing impact, say so and stop.\n\n3. **Sync English changelog**\n\n Run:\n\n ```bash\n node docs/scripts/sync-changelog.mjs\n ```\n\n This updates `docs/en/release-notes/changelog.md` from the root `CHANGELOG.md`. Never edit the docs changelog by hand.\n\n4. **Update user docs**\n\n Following the rules in `docs/AGENTS.md`, edit the affected pages in whichever locale you are working in, then sync the mirror. Match terminology with the term table in `docs/AGENTS.md` and the existing wording in surrounding pages.\n\n Cover all relevant sections:\n\n - Guides (getting-started, use cases, interaction, sessions, IDE integration)\n - Customization (skills, agents, MCP, hooks, plugins, etc.)\n - Configuration (config files, env vars, providers, data locations)\n - Reference (CLI subcommands, slash commands, keyboard shortcuts)\n - Release notes (`docs/zh/release-notes/breaking-changes.md` if a breaking change is involved)\n\n5. **Sync bilingual content**\n\n Invoke the `translate-docs` skill. It will:\n\n - Sync updated non-changelog pages between `docs/en/` and `docs/zh/`\n - Translate the English changelog → Chinese under `docs/zh/release-notes/changelog.md`\n\n## Rules and conventions\n\n- **Locale sync**: Non-changelog pages stay mirrored between `docs/en/` and `docs/zh/`. Changelog flows English → Chinese.\n- **Terminology**: Use the term table in `docs/AGENTS.md` exactly. Do not invent new translations or use synonyms.\n- **Scope discipline**: Only update sections affected by the recent changes. Do not opportunistically rewrite unrelated docs.\n- **Public examples**: Never write real internal endpoints, key names, account names, or service names into docs. Use neutral placeholders such as `https://api.example.com/v1`, `https://registry.example.com/v1/models/api.json`, `example.test`, and `YOUR_API_KEY`.\n- **Breaking changes**: If any change is breaking, also update `docs/en/release-notes/breaking-changes.md` (under `## Unreleased`) with `**Affected**` + `**Migration**` subsections, and mirror it in `docs/zh/release-notes/breaking-changes.md`.\n- **Do not edit auto-synced files**: `docs/en/release-notes/changelog.md` is regenerated by the sync script; any manual edit will be overwritten.\n\n## Common mistakes\n\n- Describing what code changed instead of what the user can now do (or can no longer do).\n- Adding a new section heading per feature instead of weaving the change into existing prose.\n- Updating only one locale and leaving its mirror stale.\n- Editing only the mirror to fix wording that should be corrected in the locale you changed first.\n- Inventing new terminology that drifts from the `docs/AGENTS.md` term table.\n- Using real internal values in examples instead of neutral `example` placeholders.\n",".agents/skills/pre-changelog/SKILL.md":"---\nname: pre-changelog\ndescription: Use before merging a kimi-code release PR to preview the user-facing CLI changelog in Chinese. Reads the changelog that changesets pre-generated in the release PR, then reuses sync-changelog's strip / classify / translate logic to render a Chinese preview. Writes no files.\n---\n\n# Pre-Changelog\n\nPreview the user-facing **Chinese** changelog of an open `kimi-code` release PR **before** it is merged. Read-only: this skill writes no files and commits nothing.\n\nThis skill reuses `sync-changelog`'s strip / classify / translate rules. Read `sync-changelog` first; only the data source (release PR diff instead of a published `CHANGELOG.md`) and the output (preview instead of docs files) differ.\n\n## Workflow\n\n### 1. Locate the release PR\n\nSelect the PR targeting the intended `release/*` branch, not the legacy main version PR. Report its latest head CI link and result alongside the preview.\n\n```bash\ngh pr list --state open --search \"ci: release packages in:title\" \\\n --json number,title,url,headRefName,baseRefName\n```\n\nPick the one with `headRefName: changeset-release/main`; record `number`, `url` as ``. If none is open, nothing to preview — stop.\n\n### 2. Read the pre-generated CLI changelog block\n\nchangesets already pre-generates `apps/kimi-code/CHANGELOG.md` inside the release PR. Extract the new version block from the diff:\n\n```bash\ngh api repos/MoonshotAI/kimi-code/pulls//files \\\n --jq '.[] | select(.filename==\"apps/kimi-code/CHANGELOG.md\") | .patch'\n```\n\nTake the added lines (`+`) from the top `## ` down to (but not including) the next `## `. That is the version block to preview.\n\nIf the CLI changelog is not in the diff (for example an SDK-only release), stop and tell the user — there is no user-facing CLI changelog to preview.\n\n### 3. Render the Chinese preview (reuse `sync-changelog`)\n\nProcess the version block exactly as `sync-changelog` does for the docs site, but only in memory:\n\n- **Strip** (`sync-changelog` step 3): drop the H1, the `### Patch Changes` / `### Minor Changes` / `### Major Changes` subheadings, PR links, and commit-hash links; keep only each entry's body text. The `Thanks [@user](...)!` credit (including the multi-author form) must be removed every time. Within each entry, drop SDK-only and provider-internal sentences (SDK capability mapping / API exposure, provider wire-format mechanics, internal XML markers, hook/event payload mechanics such as what an event reports or carries) and keep only the user-facing effect and required constraints.\n- **Merge and deduplicate** (`sync-changelog` step 4): merge micro-tweaks to the same surface into one higher-level entry; when three or more fixes target the same UI area or the same class of problem, merge them into one higher-level fix entry (do not merge broad or genuinely distinct fixes); and drop a server/API entry that only backs a web feature already listed.\n- **Collapse low-signal entries** (`sync-changelog` step 4): keep standalone only entries that pass both gates — the reader-action test (the reader must do or re-evaluate something) and the channel test (the product cannot push it into the user's path: hidden controls, habit invalidations, capabilities users would not know to seek — a control merely sitting in the UI is not surfacing, users do not explore). Polish keeps only must-react items; experiences the product shows at the moment of need (recovery cards, post-install guidance) fold. Fixes keep only behavior-change entries (readers must update a habit, config, or workaround); loud failures fold (the fix itself notifies the victim), and silent past damage folds too — the changelog does not repair the past, and a notice that names no locatable instance and no realistic action is noise, not diligence. Section sizes follow density defaults (about 2 polish, 3 fixes) that yield to genuinely qualifying entries — flag the overflow for the reviewer instead of folding to hit the number. Fold everything else into one catch-all line placed last under 修复 — `修复了一些已知问题。` (or `修复了一些已知问题，并做了若干细节优化。` when non-fix entries were also collapsed; when nothing folded is a fix, place it under 优化 instead as `做了若干细节优化和内部改进。`), followed by a separate pointer sentence: `更详细的变更记录见 [GitHub](https://github.com/MoonshotAI/kimi-code/blob/main/apps/kimi-code/CHANGELOG.md)。` (file link, no version anchor; before the release PR merges, the target does not yet contain this version's block — expected for a preview).\n- **Classify** (`sync-changelog` step 4): bucket into Features / Bug Fixes / Polish / Refactors / Other; order within each section by reader value (in Polish, user-visible improvements before protocol/internal adjustments).\n- **Translate** (`sync-changelog` step 6): translate entry bodies to Chinese; keep one sentence per entry with a parallel rhythm within a section; section headings become 新功能 / 修复 / 优化 / 重构 / 其他.\n\nIf an upstream entry is not in English, flag it and stop (changeset entries must be English).\n\n### 4. Output\n\nPrint the preview directly. Use `（预览）` as the heading because the version is not released yet. Write `无` for empty sections. Do not write any file.\n\nAfter the preview block, append a reviewer-only section titled `### 审稿参考（不进入文档）`: list every entry folded into the catch-all (short English title, one line each), note any section that exceeds the density defaults, and flag borderline calls for the reviewer to confirm. This breakdown is how reviewers see what was folded — before merge, the catch-all pointer's target does not yet contain the version's block. Never write this section into the docs pages.\n\nThe preview is pasted into chat tools (for example Lark), where relative docs links do not resolve. Rewrite every docs link to its absolute published URL: map `../.md[#anchor]` to `https://moonshotai.github.io/kimi-code/zh/.html[#anchor]` — for example `../configuration/config-files.md#loop-control` → `https://moonshotai.github.io/kimi-code/zh/configuration/config-files.html#loop-control`. Never emit raw relative paths, and never wrap a link in backticks; code-style the link text inside the brackets instead ([`loop_control`](...)).\n\n```\n发版 PR: \n\n## （预览）\n\n### 新功能\n- ...\n\n### 修复\n- ...\n```\n\n## Rules\n\n- Read-only. Never write `CHANGELOG.md`, docs files, or commit anything.\n- Classification, ordering, and translation follow `sync-changelog` exactly — do not reword or reclassify beyond what it specifies.\n- If the release PR has no CLI changelog diff, report it and stop.\n",".agents/skills/translate-docs/SKILL.md":"---\nname: translate-docs\ndescription: Translate and sync bilingual user documentation between docs/zh/ and docs/en/ following the source-of-truth rules in docs/AGENTS.md.\n---\n\n# Translate Docs\n\n## Overview\n\nThis repository keeps bilingual user documentation under `docs/zh/` and `docs/en/`. This skill synchronizes the two locales, page by page, after either side has been updated.\n\nThis skill is invoked by both `gen-docs` (incremental updates) and `audit-docs` (full pre-release audit) to keep locale mirrors in sync.\n\n## Prerequisites\n\nIf any of the following are missing, stop and report to the user before continuing:\n\n- `docs/zh/` and `docs/en/` mirrored directory structure.\n- `docs/AGENTS.md` — terminology table, typography rules, and source-of-truth rules.\n\n## Locale sync rules\n\n- **Changelog** (`release-notes/changelog.md`): English is the source. Translate to Chinese.\n- **Breaking changes** (`release-notes/breaking-changes.md`): English is the source. Translate to Chinese.\n- **All other pages**: `docs/en/` and `docs/zh/` are mirrored pairs. After either side changes, update the other locale in the same change.\n\nWhen non-changelog pages change in either locale, sync the mirror before release. When the English changelog changes, sync the Chinese changelog.\n\n## Workflow\n\n1. **Detect what needs syncing**\n\n - `git diff main..HEAD --stat docs/` — see which files changed\n - For each changed file under `docs/en/` or `docs/zh/`, locate its mirror in the other locale (same relative path).\n\n2. **Translate page by page, section by section**\n\n - Keep heading hierarchy, list structure, code blocks, callout blocks, and link targets identical between the two versions.\n - When in doubt about a technical term, **read the actual code** to confirm behavior rather than guessing.\n\n3. **Apply terminology and typography rules from `docs/AGENTS.md`**\n\n - Use the term table exactly. Do not invent translations or use synonyms.\n - English H2+ uses sentence case (proper nouns excepted, per the term table).\n - Chinese typography: full-width punctuation (`，。；：？！（）`), space between Chinese and ASCII (letters / numbers / inline code / links).\n - Callout titles (`::: tip` / `::: warning` / `::: info` / `::: danger`) use the short Chinese labels from `docs/AGENTS.md`.\n\n4. **Verify**\n\n - `git diff docs/` — scan for terminology drift or punctuation regressions.\n - Run the docs build if available (`pnpm --filter docs run build` or equivalent) to catch broken links and Markdown errors.\n\n## Rules and conventions\n\n- **Do not one-sided fixes**: if the changed locale has an unclear or incorrect statement, fix it there first; do not patch only the mirror.\n- **Match style, not just words**: Chinese docs use a narrative tone (see `docs/AGENTS.md` writing-style examples); preserve that tone in Chinese; preserve sentence-case headings and concise English style in English.\n- **Code blocks and identifiers stay as-is**: do not translate code, command names, flag names, or file paths.\n- **Public examples**: Do not introduce real internal endpoints, key names, account names, or service names while translating. Keep or replace them with neutral placeholders such as `example.com`, `example.test`, and `YOUR_API_KEY` in both locales.\n\n## Common mistakes\n\n- Rewriting only the mirror because a phrase feels awkward in the target language — fix the changed locale first, then sync.\n- Letting English headings slip into Title Case (only sentence case is allowed for H2+).\n- Forgetting to add spaces between Chinese characters and inline code or English words.\n- Translating proper nouns listed in the term table (`Wire`, `MCP`, `ACP`, `JSON`, `OAuth`, `macOS`, `uv`, etc.).\n- Updating only one direction and leaving the other locale stale — always finish all pages flagged by the diff.\n- Copying real internal values into the mirror instead of using neutral `example` placeholders.\n",".agents/skills/gen-changesets/SKILL.md":"---\nname: gen-changesets\ndescription: Use when generating changesets in the kimi-code repository — deciding whether to write one, which package to list, the bump level, the wording, and the confirmation workflow.\n---\n\n# Generate Changesets\n\nThe only user-facing published package is the CLI: `@moonshot-ai/kimi-code`. All other `@moonshot-ai/*` packages (sdk, kosong, oauth, telemetry, and so on) are internal.\n\n## 1. Whether to Write\n\nRule 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.\n\nDo not write:\n- Docs-only or tests-only changes that never enter the shipped artifact.\n- Changes internal to core/server packages — architecture, protocols, refactors, config/journal/wire mechanics — unless they fix a bug users care about.\n- When you are unsure whether users can perceive a change, ask first.\n\nDo 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).\n\n## 2. What to Write\n\nCreate a short kebab-case file under `.changeset/`:\n\n```markdown\n---\n\"@moonshot-ai/kimi-code\": patch\n---\n\nFix occasional loss of tool call results in long conversations.\n```\n\nWording:\n- One short, user-facing English sentence that states only what changed. Drop trailing clauses that explain the cause, the benefit, or the mechanism.\n- When a default flips or an existing behavior is removed, name the behavior users lose, not only the new default. State the escape hatch if one exists, e.g. `Stop hot-reloading config, skills, and AGENTS.md by default; set [watch] enabled = true or KIMI_CODE_WATCH=1 to turn it back on.`; if there is none, say plainly that the old behavior is no longer available.\n- New features: say plainly what it is plus one line on how to use it, e.g. `Add the /foo slash command to list active sessions. Run /foo to see them.`\n- Experimental features: also state how to enable them (the flag, config key, or env var).\n- No file, class, or function names, and no PR numbers. No vague words like refactor, optimize, or improve. No real internal identifiers — use neutral placeholders such as `example.com` or `YOUR_API_KEY`.\n- Internal packages' own changelogs (such as the sdk) are not curated for end users — write those entries honestly and technically.\n- One logical change per changeset; split unrelated changes into separate files.\n\n## 3. Bump Level\n\n- `patch`: bug fixes, small improvements, configuration additions to existing features — when in doubt, use this.\n- `minor`: a real new capability users could not do before (a new slash command, a new subcommand, a new mode).\n- `major`: **never write it.** If you think a change qualifies, stop and ask the user; without explicit approval fall back to `minor`, or to `patch` if `minor` is also unclear.\n\n## 4. Which Package\n\n- An internal change enters the CLI bundle and is user-perceivable → list `@moonshot-ai/kimi-code`.\n- An internal change does not enter the CLI or is not user-perceivable → write nothing; if it is written, list only that internal package.\n- Never mix packages ignored in `.changeset/config.json` with non-ignored packages in one frontmatter.\n- pi-tui exception: pi-tui-only changes list `@moonshot-ai/pi-tui`; if the same change is also visible to CLI users, write a separate CLI changeset (two files, never mixed).\n- kimi-inspect and the vis packages never appear in a changeset.\n\n## 5. Workflow\n\n1. Run `git status` / `git diff --name-only` to see which packages actually changed.\n2. Apply section 1; if no changeset is needed, stop.\n3. Pick the package and the bump, and write the one sentence.\n4. **Show the changeset text to whoever requested the work and get their confirmation before committing.**\n5. Do not guess at changes you do not understand: finish the parts that are clear, then list what is unclear and ask whether you may dig into the code.\n\nBefore a release, review the accumulated `.changeset/` entries and delete the non-user-facing ones — the release PR regenerates from `.changeset/` on the selected release branch, so deleting a file removes its changelog entry without touching shipped code.\n",".agents/skills/sync-changelog/SKILL.md":"---\nname: sync-changelog\ndescription: Use after a release succeeds, when maintainers need to sync apps/kimi-code/CHANGELOG.md into docs/en/release-notes/changelog.md and docs/zh/release-notes/changelog.md, then open a PR on a dedicated branch.\n---\n\n# Sync Changelog\n\n## Overview\n\n`kimi-code` uses changesets for versioning. Each package gets its own `CHANGELOG.md`. The user-facing CLI package, `@moonshot-ai/kimi-code`, writes its changelog here:\n\n```text\napps/kimi-code/CHANGELOG.md\n```\n\nThis file is the **only upstream source** for the documentation-site changelog. Internal package changelogs such as `packages/*/CHANGELOG.md` do not go into the documentation site.\n\nAfter the release flow finishes (Release PR merged → `Version Packages` completed → npm publish succeeded), maintainers manually run this skill to copy the new CLI changelog entries into the docs site, translate the English increment into Chinese, wait for an optional human review, then commit on a dedicated branch and open a PR.\n\n## When To Use\n\n- A new version has been published to npm.\n- The top of `apps/kimi-code/CHANGELOG.md` contains version blocks that are not yet in `docs/en/release-notes/changelog.md`.\n- The `gen-docs` flow does not run this automatically; maintainers must explicitly do it after release.\n\nDo **not** run this before the Release PR is merged. At that point, changesets has not yet written the new version into `apps/kimi-code/CHANGELOG.md`.\n\n## Source And Targets\n\n| File | Role | Edited by |\n|---|---|---|\n| `apps/kimi-code/CHANGELOG.md` | **Only upstream source**, generated by changesets | Never edit manually |\n| `docs/en/release-notes/changelog.md` | English docs changelog; source of truth for docs | This skill |\n| `docs/zh/release-notes/changelog.md` | Chinese docs changelog, translated from English | This skill, following `translate-docs` |\n\nCore rule: the English docs changelog is the source of truth, and Chinese is translated from English. This matches `translate-docs`.\n\n## Preconditions\n\nBefore editing, confirm:\n\n- The released version exists on npm (`npm view @moonshot-ai/kimi-code versions --json`) or has a matching GitHub Release tag.\n- The top of `apps/kimi-code/CHANGELOG.md` is that new version.\n\nIf any condition is not true, stop and confirm with the user.\n\nDo **not** edit or commit directly on `main`. All sync work happens on a dedicated branch created in step 1.\n\n## Workflow\n\n### 1. Prepare Branch\n\nStart from an up-to-date default branch:\n\n```bash\ngit fetch origin\ngit checkout main\ngit pull --ff-only origin main\n```\n\nBefore creating the branch, peek at the version range so the branch name matches the newest version being synced:\n\n```bash\nrg '^## ' apps/kimi-code/CHANGELOG.md | head -5\nrg '^## ' docs/en/release-notes/changelog.md | head -5\n```\n\nName the branch after the newest upstream version that is not yet in the English docs page:\n\n```text\ndocs/changelog-sync-\n```\n\nExample: syncing `0.2.1` only → `docs/changelog-sync-0.2.1`.\n\n```bash\ngit checkout -b docs/changelog-sync-\n```\n\nIf the branch already exists locally or on the remote, stop and confirm with the user instead of reusing it.\n\n### 2. Find The Version Range\n\nUse the same version lists from step 1. Confirm:\n\n- First sync: copy all upstream version blocks into the English page.\n- Incremental sync: copy every upstream version block above the latest version already present in the English page.\n\nUse upstream order: newest version first.\n\n### 3. Strip Decorations And Extract Entry Text\n\nUpstream entries look like this:\n\n```markdown\n- [#317](https://github.com/...) [`2f51db4`](https://github.com/...) Thanks [@user](https://github.com/...)! - Clean up lint warnings ...\n```\n\nChangesets may add a `Thanks ...!` credit, but it must be removed every time. Keep:\n\n- Version headings such as `## 0.2.0`.\n- Only the body text of each entry, after the PR/hash decoration and any `Thanks ...!` credit have been removed.\n\nRemove:\n\n- The upstream H1 `# @moonshot-ai/kimi-code` because the docs page already has `# Changelog`.\n- Changesets subheadings such as `### Patch Changes`, `### Minor Changes`, and `### Major Changes`.\n- PR links such as `[#317](...)`.\n- Commit hash links such as ``[`2f51db4`](...)``.\n- The `Thanks [@user](...)!` credit, including the multi-author form `Thanks [@a](...), [@b](...)!`. Drop the whole `Thanks ...!` segment every time, regardless of whether the feature is enabled.\n\nAfter stripping, each entry is `- `.\n\nDrop SDK-only and provider-internal detail. This changelog serves `@moonshot-ai/kimi-code` CLI and web users. Within an entry, keep only what CLI/web users can perceive, and remove sentences that document internals instead of user-visible behavior. Apply this on both the English and Chinese pages:\n\n- Drop sentences about how the SDK maps a capability, builds model aliases, or exposes a flag through an API such as `getExperimentalFeatures()` — that belongs in the SDK changelog, not here.\n- Drop provider / wire-format implementation mechanics (XML markers like ``, protocol field explanations, \"the wire protocol is unchanged\", cache-hit mechanics) unless they are the behavior a user perceives.\n- Drop hook/event payload mechanics — clauses about what extra fields an event payload carries or what an event reports in a specific case (for example \"enrich hook payloads with the session title and client type\", \"`SessionEnd` reports `archive` when a session is archived\"). Keep the new events or capability itself and how to configure it.\n- Keep the user-facing effect and any constraints users must follow (for example \"question texts must be unique\").\n\nDo not change facts or drop a real user-facing behavior — only trim the internal-only scaffolding. For over-long, internal-heavy entries, this trim applies on the English page too, not only in translation.\n\nUpstream language rule: `gen-changesets` requires changelog entries to be English. If the upstream CLI changelog contains a non-English entry, stop and report it to the user. Do not silently rewrite it while syncing docs.\n\nPublic-text rule: do not copy real internal endpoints, key names, account names, or service names into docs changelogs. Replace examples with neutral placeholders such as `example.com`, `example.test`, or `YOUR_API_KEY` while preserving the user-visible meaning.\n\n### 4. Merge, Deduplicate, And Classify Entries\n\nFirst, count the stripped upstream entries in the version range being synced. The count decides how much curation happens before the human review checkpoint:\n\n- **10 entries or fewer: list everything and let the user decide.** Classify every entry into its section and list them all — do not fold, merge, or drop entries on your own, and do not write a catch-all line. At the human review checkpoint (step 8), present the full list with advisory notes (which entries look low-signal under the two gates below, and why) so the user decides what stays, what merges, and what folds.\n- **More than 10 entries: curate first, then review.** Merge related entries and fold low-signal ones into the catch-all line before writing the page, using the rules below. The reviewer still owns the final cutoff — surface the borderline calls instead of resolving them silently.\n\nThe rules below are the shared curation standard: they drive the curator's fold/merge decisions when there are more than 10 entries, and they drive the advisory notes when there are 10 or fewer.\n\n- **Curate for end users: collapse low-signal entries into one catch-all line.** The docs changelog is the only curated, user-facing outlet; the full entry list always remains in the upstream package changelog, so hiding detail here loses nothing. Apply two gates to every candidate entry. Gate 1, the reader-action test: **after reading this, is there something the reader must do, or something they must re-evaluate?** Gate 2, the channel test: **is the changelog the only channel that can deliver this?** The changelog is the channel of last resort — when the product itself surfaces the information in context, at the moment of need, to exactly the affected users, the entry is redundant no matter how real the improvement is. \"Surfaced\" means pushed into the user's path, not merely present on screen: an event-triggered card, prompt, or post-install screen forces the encounter, while a toggle, menu item, command, or settings page only waits to be found. Users do not explore — a capability that lives only in ambient UI is effectively undiscoverable, so the changelog must announce it. What in-product surfacing cannot deliver: hidden controls (env vars, config keys, opt-out flags nobody would find unprompted), invalidations of existing habits or expectations (in-product discovery comes as confusion), and capabilities users would not know to seek. An entry that fails either gate folds. Anchor both gates to the changelog's reader, never to the bug's victim: someone who hit a loud failure does not need the changelog to confirm the fix — the product working again is the notification — and a reader who never hit it gets nothing from the entry.\n - `Features`: keep when users would try it or must react to it — new capabilities create demand readers did not know to seek. Collapse only behavior that takes effect solely behind an experimental flag.\n - `Polish`: keep only must-react items — a notification users may want to turn off, a behavior change to a command they already use, a default flip with an opt-out. Fold improved experiences the product surfaces in context (recovery cards, post-install guidance, progress or status displays): they are discovered at the moment of need, and pre-reading about them helps nobody. Also fold subtle or transient tweaks (status wording, spacing, animations) and internal-behavior adjustments — nobody acts on them.\n - `Bug Fixes`: keep only **behavior-change** fixes — the fix changes how something works going forward, so readers must update a habit, a config, or a widely-adopted workaround. Everything else folds, for one of two opposite reasons. Loud failures (crashes, refusals, interrupted runs): the fix itself notifies whoever was hit — announcement value falls as bug visibility rises. Silent past damage (dropped data, wrong results the user never noticed): the changelog cannot repair the past, and in this product the notice names no locatable instance and no realistic action — users cannot enumerate which old sessions were affected, and they do not audit finished sessions; a \"some past outputs may be wrong\" line is anxiety without an outlet, not diligence. The rare exception is a retrospective notice with a concrete, locatable action (for example rotating a token after a credential-handling flaw); keep those. Never keep a fix merely because it was severe, and never keep one because the bug class feels important.\n - Do not grade entries by engineering importance. Severity and effort are already represented upstream; the curated changelog is not a credit ledger — its only job is to change what the reader does or knows.\n - **Density, not quota.** Standalone sections stay short so the changelog actually gets read — as a default, expect about 2 Polish and 3 Bug Fixes entries per version, while `Features` is gated by the test alone and has no count. The defaults yield whenever more entries genuinely pass the reader-action test: keep them and flag the overflow for the human reviewer; never fold a qualifying entry just to hit the number, and never pad a section to reach it. The reviewer owns the final cutoff — the curator's job is to surface the borderline calls, not to resolve them silently.\n - Everything else collapses into a single catch-all bullet placed last under `Bug Fixes`: `Fix several known issues.` When entries beyond fixes were also collapsed, use `Fix several known issues and make various refinements.` instead (Chinese: `修复了一些已知问题。` / `修复了一些已知问题，并做了若干细节优化。`). End the catch-all line with a pointer to the upstream file so folded entries stay reachable, phrased as a separate short sentence — `See the [changelog on GitHub](https://github.com/MoonshotAI/kimi-code/blob/main/apps/kimi-code/CHANGELOG.md) for more technical entries.` (Chinese: `更详细的变更记录见 [GitHub](https://github.com/MoonshotAI/kimi-code/blob/main/apps/kimi-code/CHANGELOG.md)。`). Link the file itself, never a per-version anchor — GitHub's generated heading anchors are fragile. Keep the pointer wording restrained (\"more technical entries\"): upstream only contains changes that received a changeset, so never claim the list is complete.\n - If no fix survives, the `Bug Fixes` section is the catch-all line alone; if the whole version has no user-facing change, the version block is a single section with that line. Match the catch-all to what was folded — never claim fixes that did not happen: when the folded entries include fixes, use the forms above under `Bug Fixes`; when everything folded is polish or internal work, place the catch-all under `Polish` as `Make several refinements and internal improvements.` (Chinese: `做了若干细节优化和内部改进。`).\n- **Merge micro-tweaks to the same surface.** Collapse several small tweaks to the same UI area or feature into one concise entry at the higher level. For example, \"change the composer's default height\" and \"change the composer's default font\" merge into \"Polish the composer's default styling.\" Use the most specific common ancestor (composer, settings page, tool card, and so on). Classify the merged entry by its combined effect\n- **Merge same-surface or same-kind fixes when you have three or more.** The `Bug Fixes` section tends to accumulate many narrow UI/polish fixes that read as noise when listed one by one. When three or more fixes target the same area (for example several tool cards in the TUI, or the web session/conversation surface) or the same class of problem (for example several \"jumping/flickering/collapsing during streaming\" fixes), merge them into one higher-level entry. Examples:\n - \"Fix the Bash tool card collapsing...\", \"Fix the Edit tool card jumping in height...\", \"Fix the Edit tool card flickering while its result streams in\" → \"Fix several TUI tool cards jumping, flickering, or collapsing in height when results stream in or end with short output.\"\n - \"Fix the collapsed sidebar not hiding...\", \"Stop the chat history from replaying its entrance animation...\", \"Fix tool components jumping the conversation when expanded/collapsed\" → \"Fix several layout and display glitches when switching sessions, including the collapsed sidebar not hiding, the chat history replaying its entrance animation, and tool components jumping the conversation.\"\n - Classify the merged fixes as `Bug Fixes`.\n - **Do not over-merge.** Leave a fix standalone when it is broad, high-value, or genuinely distinct (for example model/provider tool-calling bugs, session-list corruption, file-completion gaps). Merging is for low-reader-value, similar-shape fixes that read as a wall of similar bullets. A merged fix entry must still pass the standalone test from the catch-all rule above; if the merged group is low-signal too, fold it into the catch-all line instead of listing it.\n- **Drop server/API plumbing covered by a web entry.** If one entry adds a web UI feature (for example, an Archived sessions page) and another entry only adds the server or REST/WebSocket endpoints that exist solely to power that web feature, keep the web UI entry and drop the API entry. CLI and web users perceive the web page; the backing API is implementation detail with no independent user value on this changelog. Keep the API entry only when it has independent user value — a new public endpoint that SDK or server consumers call directly, or a capability usable outside the web feature. When unsure, keep both and let the reviewer decide.\n\nThe docs changelog uses five section types:\n\n| English section | Chinese section | Meaning |\n|---|---|---|\n| `### Features` | `### 新功能` | New user-facing functionality, such as a new command, flag, mode, or capability that did not exist before |\n| `### Polish` | `### 优化` | User-visible improvements to existing functionality, including UX adjustments, behavior tweaks, and performance improvements that are not fixes or new capabilities |\n| `### Bug Fixes` | `### 修复` | Fixes for behavior that was broken |\n| `### Refactors` | `### 重构` | Internal changes with no user-visible behavior change, including build, CI, tests, dependency cleanup, and internal renames |\n| `### Other` | `### 其他` | Anything that does not fit above, such as CDN/endpoint swaps and docs-related artifacts |\n\nWith the catch-all rule above, `Refactors` and `Other` rarely appear in newly synced versions: entries with no user-perceivable effect fold into the catch-all, and an entry that does change user-perceivable default behavior (for example an engine default flip with an opt-out flag) is classified by that effect, usually `Polish`. Reserve `Other` for genuinely unclassifiable but user-facing entries. Older versions keep whatever sections they already have — do not rewrite history.\n\nClassification process:\n\n1. Classify from the stripped entry text first.\n2. If unclear, inspect the related commit or PR:\n - Use the stripped commit hash with `git show `.\n - Or use the PR number with `gh pr view `.\n3. If it is still unclear, put it in `Other`. Do not guess or force entries into `Features`.\n\nFeatures vs. Polish: ask whether the entry introduces something the user could not do before. If yes (new command, flag, mode, viewer, or capability), use `Features`. If it only improves an existing surface (a UI panel that already existed, an existing prompt, an existing tool card, an existing payload pipeline), use `Polish`. Verbs like `Add` do not automatically mean `Features` — a small visual addition to an existing UI is still polish.\n\nDefault-behavior changes: changing the default value of an existing capability (for example flipping a feature on by default) is usually `Polish`, because the capability already existed. Use `Features` only when the new default materially changes the out-of-box experience for most users in a way they could not get before. When genuinely ambiguous, flag it and confirm with the reviewer rather than guessing.\n\nKeyword hints:\n\n- **Features**: `Add ... command/flag/option/mode/viewer`, `Introduce`, `Support`, `Allow`, `Enable`, `Implement`, `New ... command/flag/option`\n- **Bug Fixes**: `Fix`, `Resolve`, `Correct`, `Address`, `Prevent ... from`, `Stop ... from`, `... no longer ...`\n- **Polish**: `Polish`, `Optimize`, `Improve`, `Enhance`, `Speed up`, `Reduce`, `Cap`, `Shorten`, `Wrap`, `Clarify`, `Tweak`, `Adjust`, `Offload`, `Show ... in existing surface`, performance and UX adjustments to existing features\n- **Refactors**: `Refactor`, `Rename`, `Clean up`, `Simplify`, `Remove unused`, `Migrate to`, `Unify`, `Restructure`, `Internal`, dependency bumps, pure CI/build/test changes\n- **Other**: docs artifacts, CDN/endpoint switches, anything that genuinely fits no other section\n\nWithin each version, section order is:\n\n```text\nFeatures → Polish → Bug Fixes → Refactors → Other\n```\n\nOmit empty sections. Within each section, order entries by reader value, not upstream order:\n\n1. Put the most valuable, obvious, and larger changes first.\n2. Prefer broad user-visible features, workflow-changing fixes, high-frequency bugs, and large cross-cutting improvements over small polish, narrow edge cases, and internal cleanup.\n3. Within `Polish`, put directly user-visible UX or performance improvements (something users can see or feel) before protocol or internal-behavior adjustments (something that makes the model or pipeline behave more reliably but is invisible to users).\n4. If entries have similar value, preserve upstream order.\n\nDo not reword or exaggerate entries just to make them look more important; only reorder existing entries.\n\n### 5. Write The English Page\n\nNever change the English page header:\n\n```markdown\n# Changelog\n\nThis page documents the changes in each Kimi Code CLI release.\n```\n\nInsert new version blocks immediately after the header paragraph and before the previous latest version.\n\nEvery version heading must carry its release date in parentheses:\n\n```text\n## (YYYY-MM-DD)\n```\n\nTake the date from the version's published GitHub Release tag, not from when you run the sync:\n\n```bash\ngit log -1 --format=%cs \"@moonshot-ai/kimi-code@\"\n```\n\nUse the half-width parenthesis form ` (YYYY-MM-DD)` on the English page. Never invent or guess a date; if the tag is missing, stop and confirm with the user.\n\nExample:\n\n```markdown\n## 0.2.0 (2026-05-26)\n\n### Bug Fixes\n\n- Fix the TUI not restoring the current todo list after resuming a session.\n\n### Refactors\n\n- Clean up lint warnings across the CLI, SDK examples, and bundled runtime code without changing product behavior.\n- Update the native release workflow to use current GitHub artifact actions.\n```\n\nDoc links: an entry that changes a documented config surface may end with a pointer to the docs page — `see [X](...) for details` (Chinese: `详见 [X](...)。`). Keep it a real Markdown link into the docs tree with a relative path (for example `../configuration/config-files.md#loop-control`). When the link text is a config key or another identifier, code-style the text inside the brackets: [`loop_control`](../configuration/config-files.md#loop-control). Never wrap the whole link in backticks — `` `[loop_control](...)` `` renders as raw inline code that exposes the relative path instead of a clickable link.\n\n### 6. Translate The Increment Into Chinese\n\nAfter updating the English page, translate only the newly added English content into `docs/zh/release-notes/changelog.md`.\n\nFollow `translate-docs`, direction `en → zh`. Changelog direction is English-to-Chinese even though many other docs flows use Chinese-to-English.\n\nChinese page requirements:\n\n- Header:\n\n ```markdown\n # 变更记录\n\n 本页记录 Kimi Code CLI 每个版本的变更内容。\n ```\n\n- Preserve version headings including the release date, but use full-width parentheses on the Chinese page, such as `## 0.2.0（2026-05-26）`. The date must match the English page; only the parenthesis style differs (half-width `()` in English, full-width `（）` in Chinese).\n- Translate section headings exactly:\n - `### Features` → `### 新功能`\n - `### Bug Fixes` → `### 修复`\n - `### Polish` → `### 优化`\n - `### Refactors` → `### 重构`\n - `### Other` → `### 其他`\n- The Chinese page must mirror the English page 1:1 for versions, sections, section order, entry order, and entry counts.\n- Keep the classification and entry order from the English page. Do not reclassify or reorder while translating.\n- Translate only entry body text. Do not add entries that are not present in English.\n- Follow `docs/AGENTS.md` for Chinese typography: full-width punctuation, spaces between Chinese and English, and the glossary.\n\n#### Chinese wording style\n\nStructural fidelity does not mean literal translation. The Chinese entries should read like a concise, idiomatic Chinese changelog. Keep the same facts as the English entry, but rephrase for natural Chinese prose.\n\nGuidelines:\n\n- **One entry, one sentence.** Avoid chaining multiple effects with commas or semicolons. If the English entry is long, split it into shorter sentences or keep only the most important effect.\n- **Drop SDK-only and provider-internal detail.** Apply the trim from step 3 while translating: keep the user-facing effect and required constraints, drop SDK-mapping sentences, provider / wire-format mechanics, and internal XML markers. A long internal entry should collapse to one short Chinese sentence about what the user gets.\n- **Prefer common changelog verbs**: 新增、支持、修复、优化、改进、调整.\n- **Avoid indirect \"through... make...\" structures**. Do not write \"通过 X，使 Y\"; prefer direct cause-effect or just state the result.\n - Bad: `通过缓存已渲染消息行，使终端在长篇对话中保持响应。`\n - Better: `缓存已渲染消息行，提升长对话下终端的响应速度。`\n- **Be specific, not vague**. Prefer concrete actions over abstract quality words.\n - Bad: `加固默认系统提示词和内置工具描述。`\n - Better: `优化默认系统提示词与内置工具描述，避免 Agent 阻塞后台任务。`\n- **Name concrete files or config keys when it helps clarity**.\n - Bad: `插件现在可以在其清单中声明 hooks。`\n - Better: `插件现支持在 kimi.plugin.json 中声明生命周期 hooks。`\n- **Include required argument placeholders in CLI options**.\n - Bad: `--allowed-host`\n - Better: `--allowed-host `\n- **Keep usage hints to one short clause**.\n - Bad: `传入 --allowed-host 以允许额外的 host。例如 ... （多句展开）`\n - Better: `例如 kimi web --allowed-host example.com。`\n- **Do not translate technical identifiers**: keep command names, flag names, file names, env vars, config keys as-is.\n- **Keep parallel rhythm within a section.** When several entries fix similar web surfaces (layout, animation, sizing), phrase them with a consistent structure (for example 修复 <问题>，现 <行为>) so the section reads as a tidy list rather than a mix of shapes.\n\nExample — translating a feature entry:\n\nEnglish source:\n\n```markdown\n- Add a --allowed-host flag to kimi web that lets extra Host header values pass the DNS-rebinding check, and include allow guidance in the 403 error message. Pass --allowed-host to allow an extra host.\n```\n\nBefore (literal, wordy):\n\n```markdown\n- 为 `kimi web` 新增 `--allowed-host` 标志，允许额外的 Host 请求头值通过 DNS 重绑定检查，并在 403 错误消息中包含允许指引。传入 `--allowed-host ` 以允许额外的 host。例如 `kimi web --allowed-host example.com`。\n```\n\nAfter (concise, idiomatic):\n\n```markdown\n- `kimi web` 新增 `--allowed-host ` 选项，可将指定 Host 加入 DNS 重绑定白名单；403 错误会提示如何通过 `--allowed-host` 或 `KIMI_CODE_ALLOWED_HOSTS` 放行，例如 `kimi web --allowed-host example.com`。\n```\n\n### 7. Verify\n\nReview:\n\n```bash\ngit diff docs/en/release-notes/changelog.md docs/zh/release-notes/changelog.md\n```\n\nCheck:\n\n- Versions and version counts match between English and Chinese.\n- Every version heading carries its release date from the published tag, with half-width parentheses in English and full-width in Chinese.\n- Each version has the same section set and order on both pages.\n- Each section has the same number of entries on both pages.\n- Within each section, the most valuable, obvious, and larger entries appear before smaller or narrower entries.\n- Entry count decided the curation level: a version range with 10 or fewer upstream entries lists everything classified, with no catch-all line (fold/merge decisions deferred to the review checkpoint); with more than 10, low-signal entries were collapsed into the single catch-all line, placed last under `Bug Fixes` — or under `Polish` when nothing folded is a fix (both the reader-action test and the channel test applied); the catch-all wording matches what was folded and never claims fixes that did not happen; section sizes stay within the density defaults (about 2 Polish, 3 Bug Fixes) unless extra qualifying entries were deliberately kept and flagged for review. The catch-all line ends with the upstream changelog pointer (file link, no version anchor).\n- PR links and commit hashes were stripped.\n- No `Thanks ...!` credit remains (remove it every time).\n- Real internal identifiers were replaced with neutral placeholders.\n- Doc links are real Markdown links (code-styled text inside the brackets when needed), never wrapped in backticks.\n- There are no empty sections.\n- Markdown indentation and blank lines are intact.\n\nThen run the docs build:\n\n```bash\npnpm --filter docs run build\n```\n\n### 8. Human Review Checkpoint\n\nAfter verification passes, **before committing**, ask the user whether they want to review the sync result. Use `AskQuestion` with options such as:\n\n- **Review first** — show the diff and wait for the user to finish checking.\n- **Skip review, commit and open PR** — proceed directly to steps 9 and 10.\n\nIf the user chooses review:\n\n1. Show the uncommitted diff:\n\n ```bash\n git diff docs/en/release-notes/changelog.md docs/zh/release-notes/changelog.md\n ```\n\n2. Summarize synced versions, section counts, and anything that needed manual classification. When the synced version range had 10 or fewer upstream entries and everything was listed, present the full entry list with advisory notes (which entries look low-signal and why) and ask the user to decide what stays, what merges, and what folds. When entries were folded into a catch-all line (more than 10 upstream entries), list every folded entry (short titles, one line each), any section that exceeds the density defaults, and every borderline call flagged during curation — the reviewer cannot own a cutoff they cannot see.\n3. Tell the user to reply when they are done reviewing, or to ask for edits.\n4. Do **not** commit, push, or open a PR until the user explicitly says review is complete, or asks to proceed.\n\nIf the user requests edits during review, make the changes, re-run verification from step 7, and return to this checkpoint.\n\n### 9. Commit\n\nOnly run this step when the user skipped review or confirmed review is complete.\n\nStage only the changelog docs files:\n\n```bash\ngit add docs/en/release-notes/changelog.md docs/zh/release-notes/changelog.md\n```\n\nUse a neutral docs-sync commit message:\n\n```text\ndocs(changelog): sync from apps/kimi-code/CHANGELOG.md\n```\n\nDo **not** create a changeset for changelog docs sync. Docs sync does not enter the bundle.\n\n### 10. Push And Open PR\n\nRun immediately after step 9.\n\nPush the branch:\n\n```bash\ngit push -u origin HEAD\n```\n\nCreate the PR with `gh pr create`. Title follows Conventional Commits:\n\n```text\ndocs(changelog): sync from apps/kimi-code/CHANGELOG.md\n```\n\nFill in `.github/pull_request_template.md`. For changelog sync PRs:\n\n- **Related Issue**: write `N/A — post-release docs maintenance` (no issue required).\n- **Problem**: the docs-site changelog is behind the published CLI release(s).\n- **What changed**: list synced version(s), note English source + Chinese translation, and mention verification (`pnpm --filter docs run build`).\n- **Checklist**: check CONTRIBUTING; explain no issue, no tests, no changeset, and that `gen-docs` is not needed because this is the dedicated changelog sync flow.\n\nExample body:\n\n```markdown\n## Related Issue\n\nN/A — post-release docs maintenance\n\n## Problem\n\nThe docs-site changelog has not yet been synced for `` after the npm release.\n\n## What changed\n\n- Synced `` from `apps/kimi-code/CHANGELOG.md` into `docs/en/release-notes/changelog.md`\n- Translated the new English increment into `docs/zh/release-notes/changelog.md`\n- Verified with `pnpm --filter docs run build`\n\n## Checklist\n\n- [x] I have read the CONTRIBUTING document.\n- [x] I have linked a related issue, or explained the problem above.\n- [ ] I have added tests that prove my feature works. (N/A — docs-only sync)\n- [x] Ran `gen-changesets` skill, or this PR needs no changeset. (No changeset — docs sync is out of bundle)\n- [x] Ran `gen-docs` skill, or this PR needs no doc update. (This PR is the dedicated changelog sync)\n```\n\nReturn the PR URL to the user when done.\n\n## Rules\n\n- The English docs changelog is the source of truth.\n- Never edit upstream `apps/kimi-code/CHANGELOG.md`.\n- Do not backfill unreleased `.changeset/*.md` drafts into the docs site.\n- If upstream wording is wrong, leave upstream alone and fix it in a future changeset.\n- A version range with 10 or fewer upstream entries is listed in full; fold/merge/drop decisions belong to the user at the review checkpoint, not the curator.\n- Always sync on a `docs/changelog-sync-*` branch and open a PR; never push changelog docs sync directly to `main`.\n- Wait for the human review checkpoint before committing, pushing, or opening a PR.\n\n## Common Mistakes\n\n| Mistake | Fix |\n|---|---|\n| Adding entries directly to the English docs page without reading upstream | Use `apps/kimi-code/CHANGELOG.md` as the source |\n| Copying PR links or commit hashes into docs | Strip them; keep only body text |\n| Leaving the `Thanks ...!` credit in docs | Remove it every time, including the multi-author form |\n| Leaving near-duplicate micro-tweaks as separate bullets | Merge small tweaks to the same surface into one higher-level entry (e.g. composer height + font → composer's default styling) |\n| Listing many narrow fixes to the same surface as separate bullets | When three or more fixes target the same UI area or the same class of problem, merge them into one higher-level fix entry; keep genuinely distinct or high-value fixes standalone |\n| Listing low-signal fixes or internal changes as standalone bullets when curating (>10 entries) | Collapse them into the single catch-all line (`Fix several known issues.`) placed last under Bug Fixes; treat the section-size defaults (about 2 Polish, 3 Bug Fixes) as a density guard, not a quota |\n| Folding, merging, or dropping entries on your own when the version range has 10 or fewer upstream entries | List everything classified, with no catch-all line, and let the user decide at the review checkpoint |\n| Folding a qualifying entry just to hit the section-size default | The defaults are density guards; keep entries that genuinely pass the reader-action test and flag the overflow for the human reviewer |\n| Keeping a fix because it was severe or hard-won | Severity makes the announcement redundant — the fix itself notifies whoever was hit; keep only behavior-change fixes and retrospective notices with a concrete, locatable action |\n| Keeping an improvement the product surfaces in context (recovery cards, post-install guidance, progress displays) | The product is the better channel — right users, moment of need; fold it (channel test) |\n| Folding a new capability because its control is visible somewhere in the UI | Visible is not discoverable — users do not explore; a toggle, menu item, or settings page that only waits to be found needs the changelog announcement |\n| Keeping a silent-impact fix out of diligence (dropped data, wrong results the user never noticed) | The changelog does not repair the past; if the notice names no locatable instance and no realistic action, it is anxiety without an outlet — fold it |\n| Overstating the catch-all pointer (for example claiming the upstream changelog is complete) | Keep the pointer restrained — `See the [changelog on GitHub](...) for more technical entries.`; upstream only contains changes that received a changeset |\n| Writing `Fix several known issues.` when nothing folded is a fix | Never claim fixes that did not happen; all-polish/internal folds go under Polish as `Make several refinements and internal improvements.` |\n| Listing a server/API entry that only backs a web feature already listed | Drop the API entry and keep the web UI entry, unless the API has independent user value |\n| Rewording upstream English entries | Upstream is frozen; copy the body text unless the user explicitly asks otherwise |\n| Leaving English text untranslated in the Chinese page | The Chinese page must be fully Chinese except preserved technical terms |\n| Editing upstream changelog text | Do not edit upstream |\n| Losing two-space indentation in multi-line list items | Restore indentation so Markdown lists stay valid |\n| Copying `### Patch Changes` into docs | Remove changesets headings and classify under Features / Bug Fixes / Polish / Refactors / Other |\n| Guessing unclear entries as Features | Inspect commit/PR; if still unclear, use Other |\n| Treating any `Add ...` line as Features | If the entry only adds a small element to an existing UI/surface, use Polish |\n| Filing UX or performance tweaks under Other | Use Polish for user-visible improvements to existing functionality |\n| Preserving upstream order when a small entry hides a larger change | Reorder within the section so the highest-value, most obvious items appear first |\n| Reclassifying entries while translating | Chinese classification must mirror English |\n| Leaving empty sections | Delete sections with no entries |\n| Putting everything under Other for convenience | Classify what can be classified first |\n| Translating tool names, command names, or config keys | Keep them as written |\n| Wrapping a whole doc link in backticks | Code-style the link text inside the brackets instead, so the link stays clickable: [`loop_control`](...) |\n| Keeping hook/event payload-mechanics clauses | Drop what an event reports or carries; keep the new capability and how to configure it |\n| Creating a changeset for docs sync | Do not create one |\n| Committing or pushing directly on `main` | Create `docs/changelog-sync-`, commit there, then open a PR |\n| Committing or opening a PR before the user skips review or confirms review is done | Wait at the human review checkpoint |\n| Using curly quotes or half-width Chinese punctuation | Follow `docs/AGENTS.md` |\n| Omitting the release date from a version heading, or guessing it | Add ` (YYYY-MM-DD)` (full-width `（）` in Chinese) taken from the published tag |\n\n## Stop Signals\n\n- The top version in `apps/kimi-code/CHANGELOG.md` is not published on npm or GitHub Releases.\n- You are about to edit `apps/kimi-code/CHANGELOG.md`.\n- You are about to add docs sync to a changeset.\n- English and Chinese versions, entry counts, or section sets do not match.\n- A section is empty.\n- A Chinese term is uncertain and `docs/AGENTS.md` does not answer it.\n- A `docs/changelog-sync-*` branch already exists for the same version and you cannot confirm whether it is stale.\n- The user asked to review but has not yet confirmed review is complete.\n","plugins/official/kimi-datasource/SKILL.md":"---\nname: kimi-datasource\ndescription: |\n Universal data-source assistant for stocks (Wind, S&P, SEC EDGAR), macro (World Bank, IMF, FRED, NBS), Chinese government data and standards (GB/HB/DB/TT), corporate, academic, legal, WHO/FAO/OECD and other IGO data, financial news (Xinhua, Caixin).\n This plugin exposes tools via MCP server `plugin-kimi-datasource_data`; call them in the flow `mcp__plugin-kimi-datasource_data__get_data_source_desc` → `mcp__plugin-kimi-datasource_data__call_data_source_tool`.\n---\n\n# kimi-datasource — 通用数据源助手\n\n## 0. 调用方式\n\n本 skill 使用 datasource MCP server 注册的两个工具，不要通过 Bash 手动执行脚本：\n\n- `mcp__plugin-kimi-datasource_data__get_data_source_desc`\n- `mcp__plugin-kimi-datasource_data__call_data_source_tool`\n\n这两个工具由 Kimi Code 托管执行，参数直接按 tool schema 传 JSON。\n\n工具会读取当前 Kimi Code 环境对应的本地 OAuth 登录凭据；当设置了 `KIMI_CODE_OAUTH_HOST` / `KIMI_CODE_BASE_URL` 时，会使用对应环境的隔离凭据。如果没有登录凭据，让用户先在 Kimi Code 里执行 `/login`。\n\n## 1. 这个 skill 提供什么能力\n\n本 plugin 后面挂了 25 个外部数据源。每一行的\"数据源名\"就是传给 `get_data_source_desc` 的 `name`。\n\n| 能力域 | 数据源名 | 典型问题 |\n|---|---|---|\n| **A股 / 港股 / 美股 行情和财务** | `stock_finance_data` | \"茅台现在多少钱\"、\"宁德时代 2024 年财报\"、\"腾讯股东\"、\"杭州的人工智能股票\" |\n| **Yahoo Finance 全球金融** | `yahoo_finance` | \"苹果分析师评级\"、\"AAPL 期权链\"、\"苹果前十大机构股东\" |\n| **世界银行历史宏观** | `world_bank_open_data` | \"中国历年 GDP\"、\"印度通胀率\"、\"各国人口增长对比\" |\n| **中国企业工商信息** | `tianyancha` | \"字节跳动股东\"、\"比亚迪司法风险\"、\"宁德时代专利\" |\n| **arXiv 论文预印本** | `arxiv` | \"找 RAG 综述\"、\"下载 2406.xxxxx\" |\n| **Google Scholar 学术搜索** | `scholar` | \"Hinton 最新论文\"、\"transformer 综述高引文献\" |\n| **中国法律法规 / 司法案例** | `yuandian_law` | \"民法典关于居住权的规定\"、\"帮我查劳动合同解除的相关法条\"、\"找几个不当得利的判例\" |\n| **Wind 万得（A股/基金/债券/宏观）** | `wind` | \"茅台今天的分钟线\"、\"十年期国债收益率走势\"、\"基金净值查询\" |\n| **IMF 国际宏观（汇率 / CPI / 预测）** | `imf` | \"美元兑人民币汇率\"、\"各国 GDP 增速预测\"、\"全球通胀率对比\" |\n| **恒生聚源智能筛选** | `gildata` | \"筛选净利润增速超 30% 且 ROE 大于 15% 的股票\"、\"基金经理筛选\" |\n| **美股 SEC 披露文件** | `sec_edgar` | \"特斯拉 10-K 年报\"、\"苹果 10-Q 季报\"、\"Form 4 内部人交易\"、\"13F 机构持仓\" |\n| **S&P Capital IQ 美股基本面** | `sp_data` | \"苹果分析师一致预期\"、\"美股估值比率对比\"、\"竞争对手关系\" |\n| **中国政府开放数据目录（国家数据局）** | `china_nda` | \"全国公共数据资源登记目录里有什么\"、\"各省开放数据平台有哪些数据集\" |\n| **国家统计局宏观指标** | `china_nbs` | \"中国历年 GDP 官方口径\"、\"各省市人口与就业统计\"、\"社会消费品零售总额\" |\n| **中国标准查询（国标 / 行标 / 地标 / 团标）** | `china_standards` | \"查 GB 国家标准全文\"、\"某行业的现行行业标准\" |\n| **WHO 全球健康** | `who` | \"全球婴儿死亡率\"、\"各国预期寿命\" |\n| **FAO 农业粮食** | `fao` | \"各国粮食产量\"、\"农产品价格\" |\n| **联合国统计司 UNdata** | `unsd` | \"联合国成员国统计年鉴表\"、\"国际贸易统计\" |\n| **欧洲央行统计** | `ecb` | \"欧元区基准利率\"、\"欧元区货币供应量\" |\n| **欧盟统计局** | `eurostat` | \"欧盟各国失业率\"、\"欧元区 CPI\" |\n| **联合国儿童基金会** | `unicef` | \"全球儿童营养指标\"、\"儿童免疫接种率\" |\n| **OECD 数据** | `oecd` | \"OECD 国家 GDP 对比\"、\"成员国教育支出\" |\n| **FRED 美国/全球宏观** | `fred` | \"美国 CPI 长时间序列\"、\"联邦基金利率走势\" |\n| **新华财经新闻公告** | `xhcj` | \"新华财经快讯\"、\"A 股公司公告\"、\"行业政策新闻\" |\n| **财新数据库** | `caixin` | \"财新数据接口检索\"、\"财新新闻与数据\" |\n\n### 选源原则\n\n1. **用户点名了数据源** → 直接用指定的源。\n2. **没点名** → 按能力域从上表选最匹配的一个；结合下面的\"能力边界参考\"和用户问题的深度、范围自行判断。\n3. **一次简单查询只选一个数据源**，不要并行读取其他源的 desc。选定的源成功返回且已经覆盖用户问题后，立即回答；不要为了补充字段、重新格式化或交叉验证继续调用其他 API。只有用户明确要求跨源对比时，才能查询第二个数据源。\n\n### 能力边界参考（客观事实，选源时考虑）\n\n- `yahoo_finance` 的外汇历史最多 2 年；`imf` 提供长期的汇率、CPI、GDP 预测和国际收支序列\n- `stock_finance_data` 的行情是实时/收盘快照；分钟级分时序列在 `wind`（另有基金、债券、国债收益率）\n- 股东 / 机构持仓：`yahoo_finance`、`sec_edgar`（13F）、`sp_data`（S&P 标准化持有人）都覆盖，口径和深度不同\n- `world_bank_open_data` 是 50 年以上的历史宏观序列；要 IMF 的预测值用 `imf`\n- `gildata` 的查询输入是自然语言条件（选股 / 选基金 / 基金经理筛选），`tianyancha` 是企业工商档案\n- `wind` 的 `indexes`/`indicators` 参数要求 Wind 原生字段名；PE/PB/ROE/总市值这类常用字段先调 `wind_search_fields` 映射（支持别名和中文，一次查一个），不要硬猜字段名\n- 中国官方统计口径：`china_nbs` 是国家统计局宏观指标序列（GDP / CPI / PPI 等，全国 / 省 / 主要城市），`china_nda` 是国家数据局的开放数据目录（回答\"有什么数据集可用\"）；`world_bank_open_data` 和 `imf` 是国际口径的历史与预测序列\n- WHO、FAO、UNSD、ECB、Eurostat、UNICEF、OECD、FRED 各自是独立数据源，按机构名直接选；IMF 自己的数据集（汇率 / CPI / GDP 预测）走 `imf`\n- 国家标准（gb）、行业标准（hb）、地方标准（db）、团体标准（tt）查 `china_standards`；法律法规与判例在 `yuandian_law`，别混\n- 新华财经（`xhcj`）偏公告 / 快讯 / 政策新闻；`caixin` 覆盖 600+ 财新数据接口，先用它的 `caixin_api_search` 找合适接口再调用\n\n**不支持的能力**：通用 Web 搜索，以及 `xhcj` / `caixin` 覆盖之外的实时新闻。\n\n## 2. 标准工作流：`get_data_source_desc` → `call_data_source_tool`\n\n后端可用 API 经常会调整，**这份 skill 故意不抄具体的 API 名和参数表**。每次调用前你都应当现场问数据源：\"你都有什么接口？\"\n\n```\n1. 根据用户问题，从上表只挑一个 data_source_name\n2. 执行 get_data_source_desc，读取该数据源的 Markdown 文档\n3. 仔细读返回的 Markdown，里面列了：\n - 该数据源整体说明（含 ticker 格式、全局约束）\n - 每个 API 的描述 / 必填参数 / 可选参数 / 默认值 / 取值范围\n4. 选最匹配的 API，按文档拼 params\n5. 执行 call_data_source_tool 取数；需要先发现接口 / 字段 / 实体的源（caixin_api_search、wind_search_fields、天眼查公司搜索），发现类调用不受“一次”限制，继续调到真正的取数 API。结果成功且已经覆盖问题时停止调用\n6. 读返回结果，用用户提问时使用的语言回答\n```\n\n### 例 1：用户问\"茅台最近一年走势\"\n\n1. 股票走势 → `stock_finance_data`\n2. 调用 `mcp__plugin-kimi-datasource_data__get_data_source_desc`，参数 `{\"name\":\"stock_finance_data\"}`\n\n3. 从文档里找到\"获取历史价格\"那个 API，看它要 `ticker / start_date / end_date / file_path` 等\n4. 用 web_search 核对 → 茅台 = `600519.SH`\n5. 调用 `mcp__plugin-kimi-datasource_data__call_data_source_tool`，参数形如 `{\"data_source_name\":\"stock_finance_data\",\"api_name\":\"<文档里写的 api>\",\"params\":{\"ticker\":\"600519.SH\",\"start_date\":\"...\",\"end_date\":\"...\",\"file_path\":\"/tmp/mao_1y.csv\"}}`\n\n### 例 2：用户问\"找几篇 retrieval augmented generation 的综述\"\n\n1. 论文搜索 → `arxiv`（或 `scholar`，arxiv 更适合预印本，scholar 引用更全）\n2. 调用 `mcp__plugin-kimi-datasource_data__get_data_source_desc`，参数 `{\"name\":\"arxiv\"}`\n\n3. 从文档里找到搜索类 API，看它要 `query / file_path / max_results` 等\n4. 执行 `call_data_source_tool`\n\n### 例 3：用户问\"字节跳动有哪些股东\"\n\n1. 企业工商 → `tianyancha`\n2. 调用 `mcp__plugin-kimi-datasource_data__get_data_source_desc`，参数 `{\"name\":\"tianyancha\"}`\n\n3. 注意：tianyancha 的 API 是动态注册的，文档会指引你**先用搜索类接口找到合适的 API 名，再调用**\n4. **必须使用企业全称**（\"北京字节跳动科技有限公司\"），不要用简称。不知道全称就先用 tianyancha 文档里的\"公司搜索\"接口查\n\n## 3. 调用前的几条铁律\n\n### 3.1 股票代码必须核对，不能凭记忆猜\n\nA 股 `.SH/.SZ/.BJ`，港股 `.HK`，美股 `.US` 等。用户通常只说中文名（\"茅台\"、\"宁德时代\"、\"腾讯\"），不会给代码。\n\n**调任何股票相关 API 前**，先用 `web_search` / `WebSearch` 一类联网工具确认正确代码 + 后缀。\n\n如果当前环境没有任何联网工具，**让用户亲口确认代码**，不要硬猜。错了的话接口会静默返回错数据或空数据。\n\n### 3.2 企业相关查询必须用全称\n\n`tianyancha` 拒收\"特斯拉\"、\"网易\"、\"腾讯\"这种简称，必须给\"北京特斯拉销售有限公司\"这种全名。不知道全名时，先调它的公司搜索 API。\n\n### 3.3 多数 API 需要 `file_path`\n\n绝大部分数据源 API 把完整结果以 CSV 形式写到 `file_path`。漏传会报 `Missing required parameters: file_path`。不知道传啥时，给一个 `/tmp/<场景>_<时间戳>.csv` 即可。\n\n### 3.4 一次调用不要堆太多 ticker\n\n`stock_finance_data` 的实时接口最多 3 个 ticker，历史接口最多 10 个。超过会被截断或报错。多了就分批调。\n\n## 4. 怎么读返回结果\n\n`call_data_source_tool` 的 stdout 一般含两段：\n\n1. **`data_preview`**：CSV 头 + 前几行（通常 1~3 行），方便你直接答简单问题\n2. **`CSV 数据已写入：/tmp/xxx.csv`**：完整数据落盘路径\n\n策略：\n- 用户只问\"XX 现在多少钱\"、\"中国 2023 GDP 多少\"这种单值 → `data_preview` 一般够，直接答\n- 用户要画图、对比、算盈亏、列清单 → 用 `Read` 工具把 CSV 读出来再处理\n- 混合 A+港股查询时服务端会自动把 CSV 拆成 `_a.csv` / `_hk.csv` 两份，原 `file_path` 那个文件不存在\n\n如果接口返回失败，提示文字一般会写明原因（参数不对 / 不支持 / 数据空等）。把人话原因反馈给用户，不要硬走第二次。\n\n## 5. `watchlist.json` — 用户自选股\n\n`${KIMI_SKILL_DIR}/watchlist.json` 是用户的自选股列表。用户问\"看一下我的自选股\"时，读这个文件，再走标准 `get_data_source_desc(\"stock_finance_data\") → call_data_source_tool` 流程查实时行情；文档里的实时接口最多 3 个 ticker 一批，多了分批调。\n\n格式：\n\n```json\n[\n {\"code\": \"600519.SH\", \"name\": \"贵州茅台\"},\n {\"code\": \"0700.HK\", \"name\": \"腾讯控股\", \"hold_cost\": 350.5, \"hold_quantity\": 100}\n]\n```\n\n- `code` 和 `name` 必填；`hold_cost` 和 `hold_quantity` 可选\n- 两者都有时顺便算盈亏：`(当前价 - hold_cost) * hold_quantity`\n- 用户说\"帮我加 XX 到自选股\"时：先 web_search 核对代码，再追加到 JSON 数组\n\n## 6. 注意事项\n\n- **回答用户时，使用用户提问时使用的语言**。如果用户用中文问，就用中文答；如果用户用英文问，就用英文答；用其他语言问，就用其他语言答。\n- **不要凭记忆猜股票代码 / 企业全称**。错代码会让接口静默返回错数据，用户察觉不到\n- **不要在没读 desc 的情况下硬传 `api_name`**。后端会报 `API_NOT_FOUND`。除非这次会话里你已经读过该数据源的 desc 并记得参数\n- **不要给投资建议**。给完数据加一句\"AI 生成，不构成投资建议\"即可\n- 如果某个数据源接口返回的报错明显是后端 bug（参数 schema 自相矛盾、内部 Python 报错等），**汇报错误给用户，不要硬试**——这种 bug 我们这边修不了，要后端服务侧改\n",".agents/skills/write-tui/SKILL.md":"---\nname: write-tui\ndescription: Use when writing or modifying the kimi-code terminal UI in apps/kimi-code/src/tui — components, dialogs/selectors, slash commands, themes, streaming render, or the KimiTUI controllers. Covers the architecture, where new features go, test placement, the theme system mechanics, and the dialog interaction/visual spec (DESIGN.md).\n---\n\n# Write TUI (apps/kimi-code)\n\nThe terminal UI lives in `apps/kimi-code/src/tui`. Before writing TUI code, read `apps/kimi-code/AGENTS.md` for the always-on **map, module boundaries, and hard constraints** (printable-key decoding, no chalk named colors, etc.). This skill is the **how-to**: architecture orientation, feature routing, test placement, theme mechanics, and the dialog spec.\n\nFor any list dialog, selector, input box, or status/toggle list, the interaction and visual rules are normative — see **[DESIGN.md](./DESIGN.md)** in this folder and follow its self-check list before submitting.\n\n## Architecture\n\n`KimiTUI` is a **coordinator** that wires state, layout, session, and dialogs together and delegates heavy logic to controllers.\n\n- `src/tui/kimi-tui.ts` — the `KimiTUI` coordinator. Holds `state`, owns startup/shutdown order, layout/editor wiring, user-input entry, sending/queueing, session lifecycle, and the slash-command handler dispatch. It should **not** accumulate event-routing or rendering logic — those live in controllers.\n- `src/tui/tui-state.ts` — `TUIState`, `createTUIState`, `createInitialAppState`. The single global UI state shape. Before adding a new global field, decide whether it truly belongs here vs. local component state.\n- `src/tui/controllers/` — the independently-testable responsibilities. Each controller owns one slice:\n - `session-event-handler.ts` — routes SDK session events (`handleEvent` dispatch + the per-event `handleXxx`). Concrete event handling goes here, not in `KimiTUI`.\n - `streaming-ui.ts` — streaming render: assistant delta, thinking, tool call / result, compaction, subagent, background agent, transcript aggregation.\n - `session-replay.ts` — resume/replay orchestration; drives replay records through the same live render hooks. Stateless replay parsing/limiting/projection helpers belong in `src/tui/utils/message-replay.ts`.\n - `tasks-browser.ts` — the tasks browser controller.\n - `editor-keyboard.ts` — editor keyboard handling, exit shortcuts, external editor, clipboard image.\n - `auth-flow.ts` — login/auth orchestration (`refreshConfigAfterLogin`, etc.).\n- `src/tui/commands/` — slash-command declaration, parsing, ordering, and dynamic skill-command generation. Parsing and types only; execution is dispatched from `KimiTUI`'s slash-command handler section, and complex execution sinks into `utils` or focused components.\n- `src/tui/components/` — pi-tui components by UI type: `chrome/` (footer, todo, welcome, loader, device code), `dialogs/` (selectors, approval/question panels, settings popups that replace the editor), `editor/` (input box + mention provider), `media/` (image, diff, code highlight), `markdown/` (the app's Markdown wrapper and mermaid art), `messages/` (transcript blocks + tool-renderers), `panes/` (activity, queue).\n- `src/tui/reverse-rpc/` — adapts SDK approval/question callbacks into UI panel data and the user's choice back into an SDK response.\n- `src/tui/theme/` — themes, color tokens, style helpers, pi-tui markdown theme, terminal-background detection. The single source of truth for color.\n- `src/tui/utils/` — TUI-only utilities (need `TUIState` or a component). App-wide, UI-independent helpers go in `src/utils/`.\n\nWhen a controller or `KimiTUI` section keeps growing, split pure functions, state projections, and presentation components into the matching directory rather than expanding the file.\n\n## Where new features go\n\nThe feature type decides the landing spot:\n\n- **CLI arguments** → `src/cli/commands.ts` / `src/cli/options.ts`, passed into the TUI via `src/cli/run-shell.ts`. The CLI never operates on the session directly.\n- **CLI subcommands** → `src/cli/sub/`, non-interactive only; reach core via `@moonshot-ai/kimi-code-sdk`.\n- **Slash commands** → declare/parse/type under `src/tui/commands/`; add the execution entry in `KimiTUI`'s slash-command handler section; sink complex logic into `utils` or a focused component.\n- **Skill-derived commands** → hook into `buildSkillSlashCommands` / the skill command map; do not hard-code a single skill.\n- **Transcript message types** → define the shape in `src/tui/types.ts`, add/extend a `components/messages/` component, register the renderer in the transcript builder.\n- **Tool-result display** → extend `components/messages/tool-renderers/registry.ts` and the renderer; do not stack branches inside `ToolCallComponent`.\n- **Popup / selector** → `components/dialogs/`, mounted via `mountEditorReplacement`; follow [DESIGN.md](./DESIGN.md). If triggered by an SDK callback, check whether `reverse-rpc/` needs an adapter/controller/handler.\n- **SDK event handling** → add the dispatch in `session-event-handler.ts`'s `handleEvent`, then the matching `handleXxx`.\n- **Streaming render** → `controllers/streaming-ui.ts`.\n- **Session start / resume behavior** → the session-management section of `KimiTUI`; replay behavior → `controllers/session-replay.ts`, reusing live render paths.\n- **Status bar / activity / queue** → `chrome/footer`, `panes/activity`, `panes/queue`, and the matching `updateXxx`.\n- **Configuration option** → read/write + schema in `src/tui/config.ts`, then the settings UI; persist through `saveTuiConfig` (a component never writes the config file itself).\n- **Constants** → shared CLI/TUI non-copy constants in `src/constant/`; TUI-only non-copy constants in `src/tui/constant/`. Component-local copy, option labels, help text, dialog titles/footers stay next to their component — do not centralize copy into a global module.\n- **General capability** → no TUI-state dependency → `src/utils/`; depends on TUI state or a component → `src/tui/utils/`.\n\n## Test placement\n\n- Component behavior tests sit next to the component's existing tests (`test/tui/components/...`).\n- Command parsing tests → `test/tui/commands/`.\n- reverse-rpc tests → `test/tui/reverse-rpc/`.\n- Pure utility tests → next to the corresponding utils tests.\n- Do not create a generic `some-feature.test.ts` just to land a small feature; extend the nearest existing test file.\n\n## Theme system mechanics\n\nThemes are managed centrally under `src/tui/theme/`:\n\n- `colors.ts` — semantic tokens: `ColorPalette`, `darkColors`, `lightColors`.\n- `styles.ts` — common chalk helpers built on top of `ColorPalette`.\n- `pi-tui-theme.ts` — the markdown/pi-tui theme config.\n- `terminal-background.ts` — terminal background detection used by auto resolution.\n- `bundle.ts` — packs `colors`, `styles`, `markdownTheme` into a `KimiTUIThemeBundle`.\n- `index.ts` / `detect.ts` — theme type and auto/dark/light resolution.\n\n> **Keep the color-token set in sync.** `ColorPalette` in `colors.ts` is the source of truth for color tokens. When you add, rename, or remove one, update its mirrors in the same change: the custom-theme JSON schema (`apps/kimi-code/src/tui/theme/theme-schema.json`), the token tables in the custom-theme docs (`docs/en/customization/themes.md` and `docs/zh/customization/themes.md`), and the token table in the `custom-theme` built-in skill (`packages/agent-core-v2/src/features/skill/catalog/builtin/custom-theme.md`).\n\nApply / switch flow:\n\n- UI entry: `ThemeSelectorComponent` → `handleThemeCommand` → `applyThemeChoice`.\n- The real apply step is `KimiTUI.applyTheme`: it updates `state.theme`, `state.appState.theme`, and notifies components to refresh their palette.\n- Persist the choice through `saveTuiConfig` — a component must not write the config file itself.\n\n> The **hard color rules** (no chalk named colors, contrast ratios, no module-top-level cached styled functions, add a `ColorPalette` token before inventing a color) are normative and guard-enforced — they live in `apps/kimi-code/AGENTS.md`. This skill only covers the mechanics.\n\n## Before you submit\n\n- Run lint / format / test on the files you changed.\n- For any dialog/selector/input/toggle list, walk the self-check list at the end of [DESIGN.md](./DESIGN.md).\n- Keep `printableChar()` for printable-key comparisons (CI guard) and `chalk.hex(colors.)` for color (CI guard).\n","plugins/official/kimi-webbridge/skills/kimi-webbridge/SKILL.md":"---\nname: kimi-webbridge\ndescription: |\n Kimi Browser Extension（Kimi 浏览器扩展，原 Kimi WebBridge）lets AI control the user's real browser — navigate, click, type, read, screenshot, and interact with any website using the user's actual login sessions. Use this skill whenever the user wants to interact with websites, automate browser tasks, scrape web content, or perform any action requiring a real browser. Also use when the user mentions \"browser\", \"webpage\", \"open URL\", \"screenshot\", or asks to read/interact with any website. Use even for simple-sounding browser requests — the daemon handles all complexity.\nmetadata:\n version: \"2.0.11\"\n---\n\n# Kimi Browser Extension (formerly Kimi WebBridge)\n\nControl the user's real browser (with their login sessions) via a local daemon at `http://127.0.0.1:10086` (the default address — see [If a tool call fails](#if-a-tool-call-fails-daemon-or-extension-not-ready) for when it differs).\n\n## Tools\n\n| Tool | Args | Returns | Note |\n|------|------|---------|------|\n| `navigate` | `url`, `newTab`(bool), `group_title` | `{success, url, tabId}` | First call opens a tab — see [Tabs](#tabs-and-the-current-tab). `group_title` sets the group's visible label |\n| `find_tab` | `url`, `active`(bool) | `{success, url, tabId, borrowed}` | Re-select a tab **this session** opened; `active:true` borrows the tab the **user** is viewing — see [Tabs](#tabs-and-the-current-tab) |\n| `snapshot` | — | `{url, title, tree}` with `@e` refs | **Accessibility tree** (text) — use this to read page content and locate elements |\n| `click` | `selector` (@e ref or CSS) | `{success, tag, text}` | Synthetic `el.click()` |\n| `fill` | `selector`, `value` | `{success, tag, mode}` | Works on ``/`