Communitygithub.com

MoonshotAI/agent-core-dev

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.

agent-core-dev 是什么?

agent-core-dev is a Claude Code agent skill that 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.

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/MoonshotAI/kimi-code/tree/main/.agents/skills/agent-core-dev

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

agent-core-dev 是做什么的?

Develop packages/agent-core-v2 by lifecycle stage. This skill is self-contained: every rule, recipe, and red line lives in the stage files below — it does not delegate to packages/agent-core-v2/docs/.

agent-core-v2 is the new agent engine built on the DI × Scope architecture (a port of packages/agent-core). Everything resolves through the container: a service declares an identity, its dependencies, and a lifetime; the container decides construction, singleton-per-scope, ordering, and disposal. The stage files restate the rules in imperative form so you can work without reading the source docs.

Lifecycle at a glance

Orient → Design → Implement → Test → Verify
  │        │          │          │        │
  │        │          │          │        └─ lint:domain · typecheck · test · dep graph · red lines
  │        │          │          └─ test.md
  │        │          └─ implement.md (+ errors.md · flags.md · permission.md)
  │        └─ design.md
  └─ orient.md

Stages are ordered but not strictly linear: a test failure (stage 4) that reveals a wrong scope sends you back to design (stage 2); a CyclicDependencyError sends you to design.md §dependency-direction and implement.md §cycles.

Workflows

End-to-end procedures that span the stages. Reach for these before reading the stage files individually.

  • Align (port agent-coreagent-core-v2): split a v1 class into semantic units, fix each unit's domain / scope / Service / dependencies, then migrate the logic and tests. Use when the task is "move feature X from v1 to v2" or "port IXxxService to v2".
  • Commit align (triage a main commit against v2): given one main commit hash + a short note, find the v1 logic it changed, check whether v2 already has the corresponding implementation, bucket it (aligned / partial / missing / not-applicable), and recommend a minimal fix. Use in the kimi-code-v2-catching-up-to-main phase, for one commit at a time; escalate to align.md if the gap is a whole domain.
  • Server align (expose agent-core-v2 over server-v2): wire a v2 domain into packages/kap-server over /api/v2 (native) and /api/v1 (v1-compatible mirror), keep the wire schema byte-compatible with the established v1 contract by sharing the @moonshot-ai/protocol schema, and isolate v1-only behavior in a <domain>Legacy edge adapter instead of distorting the native v2 Service. Use when the task is "expose the new v2 Service on the server", "add a route to the /api/v1 surface", or "keep server-v2 wire-compatible with released v1 clients".

Stages

  • Stage 1 — Orient: the DI black box (identity / dependencies / lifetime), the four LifecycleScope tiers and visibility, and the file-header comment convention. Read before touching business code.
  • Stage 2 — Design a service: pick a scope, split a domain across scopes, choose a calling style (direct call vs event vs hook), and direct dependencies. Decide where things live and who knows whom before coding.
    • Topic: Domain boundaries vs Scope — keep session / agent / turn from becoming god objects; data-ownership test and their split conclusions.
    • Topic: Persistence layering — the three-layer Store → Storage → backend model, naming Stores by access pattern, and which layer business code should depend on.
    • Topic: Edge exposure — resource:action + WS events — which Services are exposed over /api/v2 (per-scope action map) and which events stream over WS; what to wrap in a facade.
  • Stage 3 — Implement: the standard Service recipe and the DI building blocks — interface + identity, constructor injection, scoped registration, Disposable, eager vs delayed, invokeFunction, createInstance, child scopes, and the cycle-refactor playbook.
    • Topic: Service authoring — file layout, naming, contract vs impl contents, interface style, constructor/field conventions, events, multi-Service domains, comment rules.
    • Topic: Config — the section-registry model, App vs Session split, owning a config section, the TOML format, and the env overlay.
    • Topic: Errors — co-located XxxError, the central code registry, wire serialization, boundary translation.
    • Topic: FlagsregisterFlagDefinition, IFlagService.enabled(id), the [experimental] config section, resolution precedence.
    • Topic: Permission — composable chain-of-responsibility kernel, policy registry + composer, modes/agentTypes metadata, resolveExecution/accesses.
    • Topic: Telemetry — emitting events via ITelemetryService, context propagation, and appender destinations (ConsoleAppender / CloudAppender).
  • Stage 4 — Test: resolve the system under test by interface, pick TestInstantiationService vs createScopedTestHost, shared stubs, service groups, teardown.
  • Stage 5 — Verify & submit: lint:domain, typecheck, test, and the pre-submit checklist.

How to use this skill

Jump to the stage you are in and read that one file; each is self-contained and ends with its own red lines. Skim the global red lines below before submitting — they catch most mistakes across every stage. The repo's source of truth remains the code in packages/agent-core-v2/src/; this skill codifies the same rules so you do not have to re-derive them.

Global red lines

Invariants that hold across every stage. Each is expanded in the stage file noted.

  1. No new on a class whose constructor carries @IService deps — inject with @IX or accessor.get(IX). (implement.md)
  2. @IX decorates constructor parameters only; parameter order depends on construction (static-first for createInstance, @IX-first for scoped services). (service-authoring.md)
  3. Both interface and impl carry _serviceBrand; the createDecorator name is globally unique. (implement.md)
  4. Parent scope never depends on child scope — short-lived may inject long-lived, never the reverse. (orient.md)
  5. No cyclic dependencies — refactor (extract a third Service / use an event / re-scope); do not break the cycle with Delayed. (design.md, implement.md)
  6. ServicesAccessor is valid only during invokeFunction — never stash it for async use. (implement.md)
  7. Scope follows state identity — no Map<sessionId, …> at App to fake per-session state. (design.md)
  8. Foundational layers never know upstream ones; business code never depends on the edge layer (gateway/rpc). (design.md)
  9. Throw coded errors; register codes centrally; branch on code across the wire, never instanceof. (errors.md)
  10. Gate unreleased behavior behind a flag contributed via registerFlagDefinition and resolved through IFlagService.enabled(id); no ad-hoc env toggles. (flags.md)
  11. Tests resolve the SUT by interface; shared stubs live under test/, never src/. (test.md)
  12. Config is the preference registry: only preferences that are persistable, schema'd, and user/operator-facing go in IConfigService. Domain-specific config (including env-only operational toggles) goes through registerSection + envOverlay. Facts → IBootstrapService (kept domain-agnostic — never add cron/flags/model state); session state → Session scope; constants → code. Business domains never call IBootstrapService.getEnv() directly. (config.md)

Individual skills in this repo

This repo contains 13 individual skills — each has its own dedicated page.

MoonshotAI/agent-core-review

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.

MoonshotAI/consolidate

Apply an approved sub-skill grouping by moving user-specified skills into a parent bundle, with timestamped backups of every modified directory.

MoonshotAI/gen-changesets

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.

MoonshotAI/gen-docs

Update Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience.

MoonshotAI/kimi-datasource

Universal data-source assistant. Use this skill when the user wants external structured data such as stocks, financial reports, technical indicators, A-share/HK/US markets, global macroeconomics, Chinese enterprise registry information, arXiv papers, Google Scholar results, or Chinese laws/regulations and judicial cases. 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`.

MoonshotAI/pre-changelog

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.

MoonshotAI/review

Analyze the available skill set and recommend candidate groups that could be consolidated into sub-skill bundles. Read-only — proposes a plan, does not move files.

MoonshotAI/slop

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.

MoonshotAI/sub-skill

Discover and reorganize the skill inventory into hierarchical sub-skill bundles. Use when the user asks to review, group, or consolidate skills into a parent bundle.

MoonshotAI/sync-changelog

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.

MoonshotAI/test

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).

MoonshotAI/translate-docs

Translate and sync bilingual user documentation between docs/zh/ and docs/en/ following the source-of-truth rules in docs/AGENTS.md.

MoonshotAI/write-tui

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).

相关技能