Apothem vs raw Kimi Code config

[Machine-seeded — pending review] This page is seeded from the English source and awaits native-language review per the i18n review gate.

Kimi Code reads project-root AGENTS.md as its instruction file and keeps project configuration under <project>/.kimi-code/, including the operator-owned .kimi-code/mcp.json MCP surface. You can author that instruction file and its supporting cohorts by hand, per project, forever. Apothem's kimi-code adapter renders the governance surface into AGENTS.md as a managed block from the shared profile and keeps it consistent across every harness and every project. This page contrasts hand-maintaining that config against managing it with Apothem.

Effort comparison

What Apothem manages

The kimi-code adapter renders the shared rules and governance surface into the project-root AGENTS.md managed block and installs the commands, skills, hooks, agents, rules, and templates cohorts under .kimi-code/.apothem/support/. It does not author .kimi-code/mcp.json; the MCP surface stays operator-owned. The rendered instruction surface drives the project directly. Every change to the shared rules re-renders the files on the next apothem update.

Migration path

1. Run apothem profile init to create the shared profile if you have not yet.
2. Move the rules from your existing AGENTS.md into the shared corpus.
3. Run apothem install --harness kimi-code to render the AGENTS.md instruction surface and the .kimi-code/.apothem/support/ support tree.
4. Run apothem verify --harness kimi-code to confirm the config landed.
5. Use apothem update --harness kimi-code for every later change.

Read next

• Kimi Code adapter reference
• Comparison overview