Apothem vs raw Kimi Code config
Hand-maintaining Kimi Code's project-root AGENTS.md and .kimi-code/ support files versus rendering them from Apothem's shared profile.
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
| Task | Raw hand-config | Apothem-managed |
|---|---|---|
Author the AGENTS.md instruction surface | Hand-write and re-sync per project | One managed block rendered from the shared profile |
| Keep rules, commands, skills, agents in sync | Manual copy per project | Skills and commands (as skills) under <project>/.kimi-code/skills/; helpers as sub-agents under <project>/.kimi-code/agents/; rules, hooks, and templates under <project>/.kimi-code/.apothem/support/, on every install |
| Preserve operator prose on refresh | Manual merge | Sentinel-delimited block; operator prose outside it is preserved |
| Keep rules aligned with other harnesses | Manual, per tool | Automatic on apothem update |
| Verify the config is correct | Manual inspection | apothem verify --harness kimi-code --project <path> |
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 skills, and the commands
wrapped as skills, in .kimi-code/skills/, the project skills directory Kimi Code
loads. The helpers become Kimi Code sub-agents in .kimi-code/agents/, with
their tool names translated to the ones Kimi Code matches. The hooks, rules, and
templates cohorts go under .kimi-code/.apothem/support/: Kimi Code reads hooks
from the user-scope ~/.kimi-code/config.toml, which the adapter does not write.
The adapter does not author .kimi-code/mcp.json; the MCP surface
stays operator-owned. Kimi Code reads project instructions from AGENTS.md or .kimi-code/AGENTS.md; the
adapter writes only the project-root AGENTS.md, and the Kimi Code
documentation does not say which of the two files wins when both exist. Every
change to the shared rules re-renders the files on the next apothem update.
Migration path
- Run
apothem profile initto create the shared profile if you have not yet. - Move the rules from your existing
AGENTS.mdinto the shared corpus. - Run
apothem install --harness kimi-code --project <path>to render theAGENTS.mdinstruction surface, the.kimi-code/skills/skills, the.kimi-code/agents/sub-agents, and the.kimi-code/.apothem/support/support tree. - Run
apothem verify --harness kimi-code --project <path>to confirm the config landed. - Use
apothem update --harness kimi-code --project <path>for every later change.