Kimi Code

Vendor: Moonshot Install name: kimi-code Status: GA Native config: <project>/AGENTS.md, <project>/.kimi-code/skills/, <project>/.kimi-code/agents/, and <project>/.kimi-code/.apothem/support/

InstallationCopy Anchor Link

apothem install --harness kimi-code --project /path/to/project

The adapter writes the shared Apothem governance surface into the project-root AGENTS.md as a sentinel-delimited managed block (operator prose outside the sentinels is preserved). It installs skills, and commands wrapped as skills, in Kimi Code's native project skills directory, <project>/.kimi-code/skills/, and Apothem's helpers as Kimi Code subagents in <project>/.kimi-code/agents/ (see Subagents). The other cohorts stay under the Apothem-owned support tree at <project>/.kimi-code/.apothem/support/. A project AGENTS.md is read by many coding tools besides Kimi Code, so the block is written as project-wide guidance that names no single tool as its reader.

Kimi Code reads the project-root AGENTS.md instruction file following the universal AGENTS.md convention, and project configuration lives under <project>/.kimi-code/. Kimi Code takes the project root to be the nearest directory containing .git, searching upward from the working directory, so pass the repository root as --project. The <project>/.kimi-code/mcp.json surface is operator-owned; Apothem names it but authors no entries.

Files written: <project>/AGENTS.md (managed block), the skills and the commands (as skills) under <project>/.kimi-code/skills/, one <project>/.kimi-code/agents/<name>.md for each Apothem helper, and the hooks, rules, and templates cohorts under <project>/.kimi-code/.apothem/support/.

SubagentsCopy Anchor Link

Kimi Code reads a subagent from a Markdown file in .kimi-code/agents/ (or .agents/agents/), per the Kimi Code documentation on custom subagents. The install writes one file per Apothem helper into <project>/.kimi-code/agents/ for all fourteen helpers. It installs for the project only and writes no ~/.kimi-code/agents/ folder.

Each file keeps the helper's instructions unchanged and carries these frontmatter keys:

Kimi Code matches tool names exactly, with capitals, and warns about a name it has no tool for. So the install renames the two tools Kimi Code spells differently, WebFetch to FetchURL and TodoWrite to TodoList, and leaves out the names Kimi Code has no tool for: MultiEdit, NotebookEdit, PowerShell, Monitor, Artifact, TaskCreate and TaskUpdate. A denied tool stays denied. If a helper's allowed tools all disappear this way, the file carries tools: [], which allows no tool; an omitted tools would allow every tool.

The install never writes model (Kimi Code has no model key for a subagent, which uses the model of the main session or the [secondary_model] in config.toml), override (it would let a project file replace a built-in subagent), subagents, whenToUse, or Apothem's maxTurns, version, updated and portability keys.

Things to know:

• The subagent files are ordinary project files. Commit them with the project or list .kimi-code/agents/ in .gitignore; Apothem does not choose for you.
• Kimi Code uses a helper when delegation is requested. Since its release of 2026-10-25 it handles tasks itself by default instead of launching subagents on its own, so ask for a helper by name, in a message or in AGENTS.md. The vendor's page on custom subagents still describes automatic scheduling, so this may change.
• A project-level file in .kimi-code/agents/ ranks above a definition with the same name at the extra, user and plugin levels. Give your own helpers names that differ from Apothem's. Kimi Code's code also reads .kimi-code/agents/ before the shared .agents/agents/ folder, which Apothem never writes, and keeps the first of two same-named files; the documentation does not say.
• A file of yours with an Apothem helper's name is saved under ~/.apothem/backups/ and then replaced. The uninstall does not put it back. Files with other names are never touched.
• Earlier releases kept the helper files in the support tree, at .kimi-code/.apothem/support/agents/, where Kimi Code did not load them. An apothem update or apothem uninstall removes that copy after saving it under ~/.apothem/backups/.

Profile-to-native-config mappingCopy Anchor Link

The adapter reads Apothem's shared profile and renders the project-root AGENTS.md instruction surface on every apothem install or apothem update run. The behavioral rules and governance corpus land in the managed block of AGENTS.md. Each skill, and each command wrapped as a skill, lands at .kimi-code/skills/<name>/SKILL.md, a project skills directory Kimi Code loads. The adapter writes only that Kimi-specific folder and never .agents/skills/, which other tools also read. Skills you add to .kimi-code/skills/ yourself under other names are kept on install, update, and uninstall. A skill there with the same name as an Apothem skill is replaced: install and update overwrite it, and uninstall removes it, each after a timestamped copy under ~/.apothem/backups/, and the install prints no notice of the collision. Give your own skills names that differ from Apothem's.

The hooks, rules, and templates cohorts are placed under .kimi-code/.apothem/support/ and referenced from the instruction surface. Kimi Code does not load them from the support tree, so the Apothem copies there are reference material the AGENTS.md block points to. The block ends with an Apothem support files section that names, relative to the project root, the directory under .kimi-code/.apothem/support/ each repository-style citation (rules/<name>.md, templates/..., hooks/...) resolves against, so a committed AGENTS.md carries no machine-specific path. (Kimi Code behavior per its customization pages for skills, helper definitions, and hooks, read 2026-10-24 for skills and hooks, 2026-10-27 for helper definitions.)

Not installed nativelyCopy Anchor Link

Kimi Code documents a native place for hooks. The adapter does not write to it yet, for these reasons.

• Hooks. Kimi Code reads hooks from the [[hooks]] array in ~/.kimi-code/config.toml ($KIMI_CODE_HOME/config.toml when that variable is set). Apothem writes none. That file is user scope while this adapter writes under the project root; an entry allows only four fields (event and command required, matcher and timeout optional) and an extra field stops the config from loading; and Apothem has no TOML merge that could later remove only its own entries. The hook helper scripts stay in the support tree.
• Skill frontmatter. The vendor page documents the SKILL.md keys name and description (both required), type, whenToUse, disableModelInvocation (also accepted as disable-model-invocation), and arguments. It states no rule for other keys. Skills install with the frontmatter they have in the Apothem source, so keys such as version, updated, archetype, userInvocable, argument-hint, portability, and allowed-tools reach Kimi Code, which may ignore or reject them.
• Same-name skills. Kimi Code gives the project level priority over the user level, so a skill in <project>/.kimi-code/skills/ takes precedence over a skill of the same name in ~/.agents/skills/, which a different Apothem adapter writes. The vendor page does not say how .kimi-code/skills/ and .agents/skills/ rank against each other inside the project level.

Compatibility notesCopy Anchor Link

Kimi Code reads project instructions from AGENTS.md or .kimi-code/AGENTS.md and recognizes .kimi-code/mcp.json as the operator-owned MCP surface; Apothem names that surface but authors no entries into it. Of the two instruction files, the adapter writes only the project-root AGENTS.md, which Kimi Code reads as project instructions; the Kimi Code documentation does not say which of the two files wins when both exist. Kimi Code exposes no statusline or output-style file surface, so those cohorts are not materialized.

Kimi Code runs on the Kimi model family from Moonshot; see the vendor configuration reference for the current model and configuration surface.

VerificationCopy Anchor Link

apothem verify --harness kimi-code --project /path/to/project

The verify command confirms that:

1. The native config exists at the expected path.
2. Each managed target exists, including the skills and subagent directories; managed files are non-empty, and JSON or YAML configs parse. Add --profile PATH to also confirm that the installed files match that profile. For .kimi-code/agents/ the check is that the folder exists, not that each helper file is in it; the command apothem diff --harness kimi-code --project /path/to/project lists the helper files that are missing or out of date.
3. The adapter-specific verification routine reports success.

UpdatingCopy Anchor Link

apothem update --harness kimi-code --project /path/to/project

Re-derives the project-root AGENTS.md managed block, the skills, the subagent files, and the support cohorts from the current shared profile state. An update over an install made before skills moved to .kimi-code/skills/ removes the old <project>/.kimi-code/.apothem/support/skills/ directory, so each skill is present once. An update over an install from before the helpers moved to .kimi-code/agents/ removes the old <project>/.kimi-code/.apothem/support/agents/ directory the same way. A timestamped copy of each removed directory is saved under ~/.apothem/backups/ first.

UninstallingCopy Anchor Link

apothem uninstall --harness kimi-code --project /path/to/project

Removes the Apothem block from the project-root AGENTS.md and keeps any text outside the sentinels. The file is deleted only when nothing else remains in it. Also removes the skills Apothem placed under <project>/.kimi-code/skills/ (skills you added there under other names are kept), the subagent files under <project>/.kimi-code/agents/ (files you added there under other names are kept, and the folder is removed when it is left empty), and the support files under <project>/.kimi-code/.apothem/support/, including the old support-tree skills/ and agents/ directories of an install that was never updated. Before the change, a timestamped copy of each file is saved under ~/.apothem/backups/; no backup file is left in the project. The shared profile YAML and Apothem engine are unaffected.

Conformity gateCopy Anchor Link

python -m apothem.conformity.gate --all .

TroubleshootingCopy Anchor Link

Configuration knobsCopy Anchor Link

See alsoCopy Anchor Link

• All harnesses — the full catalog of supported tools
• Install guide — install Apothem into this harness
• apothem harnesses reference — list and inspect adapters from the CLI