ワンクリックで
gen-docs
Update Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Update Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when developing in packages/agent-core-v2 (the DI × Scope agent engine) — adding or modifying a domain Service, choosing a LifecycleScope, wiring DI dependencies, splitting a domain across scopes, owning or migrating a config section, gating behavior behind an experimental flag, raising coded errors, working on the permission system, writing DI/Scope tests, porting business logic from agent-core (v1) to v2, triaging a main-branch commit against v2, or exposing a v2 domain over server-v2 while keeping the /api/v1 wire contract compatible with released clients. Self-contained guide organized by development stage (orient → design → implement → test → verify) plus align workflows for v1→v2 migration, main-branch commit triage, and server-v2 wire exposure; each file carries the rules, examples, and red lines for its step.
Use when generating changesets in the kimi-code repository, including package bump selection, internal package and CLI bundle handling, bump levels, major confirmation, and English changelog wording.
Use ONLY for code review and test write/review guidance in `packages/agent-core-v2` (the DI × Scope agent engine). Does NOT apply to the legacy `packages/agent-core` or to any other package — for those, do not load this skill. Groups the review and testing lenses used for agent-core-v2 — `slop` (single-level-of-abstraction / layered error-handling review, invoked only on explicit request) and `test` (contract-driven per-test rules for both authoring and reviewing tests). Apply the sub-skill that matches the task; do not apply `slop` unprompted.
Invoke only when the user explicitly asks to review code through the "single level of abstraction / layered error handling" lens — a function does only its own layer's business logic while errors are handled above or below. The agent reports detections, raw-count measurements, and move directions. Apply only when the user explicitly requests this lens.
Use when writing or reviewing tests, or when asked how to write a good single test. Encodes the per-test rules behind the "test the contract / responsibility, not the implementation" principle — name and structure one behavior per `it`, drive through the public surface, stub only true external boundaries, control time and config via documented knobs, and keep tests clear, isolated, and refactor-resilient. The same rules drive both authoring (write mode) and auditing existing tests (review mode).
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.
| name | gen-docs |
| description | Update Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience. |
This 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.
Use this skill to update the corresponding documentation whenever the codebase has changes that affect product behavior or user experience.
For a full pre-release audit of all pages (detecting hallucinations and coverage gaps), use the audit-docs skill instead.
This skill depends on the following being in place. If any are missing, stop and report to the user before continuing:
docs/ directory with docs/zh/, docs/en/, and docs/.vitepress/config.ts set up (VitePress site).docs/AGENTS.md style guide — defines source-of-truth rules, terminology table, typography, and writing style.docs/scripts/sync-changelog.mjs — auto-syncs root CHANGELOG.md to docs/en/release-notes/changelog.md.translate-docs skill in .agents/skills/ — handles bilingual synchronization.Inspect changes
git log main..HEAD --oneline — commits on the current branchgit diff main..HEAD --stat — file-level scopels .changeset/*.md (excluding README.md) — pending changeset entriesCHANGELOG.md and any subpackage packages/*/CHANGELOG.md for already-recorded entries.Understand user-facing impact
For each change, read the actual implementation when needed; do not infer behavior from commit messages or PR titles alone. Skip:
If after the scan you conclude there is no user-facing impact, say so and stop.
Sync English changelog
Run:
node docs/scripts/sync-changelog.mjs
This updates docs/en/release-notes/changelog.md from the root CHANGELOG.md. Never edit the docs changelog by hand.
Update user docs
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.
Cover all relevant sections:
docs/zh/release-notes/breaking-changes.md if a breaking change is involved)Sync bilingual content
Invoke the translate-docs skill. It will:
docs/en/ and docs/zh/docs/zh/release-notes/changelog.mddocs/en/ and docs/zh/. Changelog flows English → Chinese.docs/AGENTS.md exactly. Do not invent new translations or use synonyms.https://api.example.com/v1, https://registry.example.com/v1/models/api.json, example.test, and YOUR_API_KEY.docs/en/release-notes/breaking-changes.md (under ## Unreleased) with **Affected** + **Migration** subsections, and mirror it in docs/zh/release-notes/breaking-changes.md.docs/en/release-notes/changelog.md is regenerated by the sync script; any manual edit will be overwritten.docs/AGENTS.md term table.example placeholders.