Kimi Code

Éditeur : Moonshot Nom d'installation : kimi-code Statut : GA Configuration native : <project>/AGENTS.md, <project>/.kimi-code/skills/, <project>/.kimi-code/agents/ et <project>/.kimi-code/.apothem/support/

InstallationCopy Anchor Link

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

L'adaptateur écrit la surface de gouvernance partagée d'Apothem dans le AGENTS.md à la racine du projet, sous la forme d'un bloc géré délimité par des sentinelles (la prose de l'opérateur située hors des sentinelles est préservée). Il installe les skills, ainsi que les commandes enveloppées en skills, dans le répertoire natif des skills de projet de Kimi Code, <project>/.kimi-code/skills/, et les auxiliaires d'Apothem en tant que subagents Kimi Code dans <project>/.kimi-code/agents/ (voir Subagents). Les autres cohortes restent sous l'arborescence de support détenue par Apothem, à <project>/.kimi-code/.apothem/support/. Un AGENTS.md de projet est lu par de nombreux outils de développement en plus de Kimi Code ; le bloc est donc rédigé comme une consigne valable pour tout le projet, qui ne désigne aucun outil unique comme son lecteur.

Kimi Code lit le fichier d'instructions AGENTS.md à la racine du projet selon la convention universelle AGENTS.md, et la configuration du projet se trouve sous <project>/.kimi-code/. Kimi Code considère comme racine du projet le répertoire le plus proche qui contient .git, en remontant depuis le répertoire de travail ; passez donc la racine du dépôt comme --project. La surface <project>/.kimi-code/mcp.json est détenue par l'opérateur ; Apothem la nomme mais n'y rédige aucune entrée.

Fichiers écrits : <project>/AGENTS.md (bloc géré), les skills et les commandes (sous forme de skills) sous <project>/.kimi-code/skills/, un <project>/.kimi-code/agents/<name>.md pour chaque auxiliaire Apothem, et les cohortes de hooks, de règles et de templates sous <project>/.kimi-code/.apothem/support/.

SubagentsCopy Anchor Link

Kimi Code lit un subagent depuis un fichier Markdown dans .kimi-code/agents/ (ou .agents/agents/), selon la documentation de Kimi Code sur les subagents personnalisés. L'installation écrit un fichier par auxiliaire Apothem dans <project>/.kimi-code/agents/, pour les quatorze auxiliaires. Elle installe pour le projet uniquement et n'écrit aucun dossier ~/.kimi-code/agents/.

Chaque fichier conserve les instructions de l'auxiliaire inchangées et porte ces clés de frontmatter :

Kimi Code fait correspondre les noms d'outils exactement, majuscules comprises, et émet un avertissement pour un nom auquel ne correspond aucun outil. L'installation renomme donc les deux outils que Kimi Code orthographie différemment, WebFetch en FetchURL et TodoWrite en TodoList, et omet les noms pour lesquels Kimi Code n'a aucun outil : MultiEdit, NotebookEdit, PowerShell, Monitor, Artifact, TaskCreate et TaskUpdate. Un outil refusé reste refusé. Si tous les outils autorisés d'un auxiliaire disparaissent ainsi, le fichier porte tools: [], qui n'autorise aucun outil ; un tools omis autoriserait tous les outils.

L'installation n'écrit jamais model (Kimi Code n'a aucune clé de modèle pour un subagent, qui utilise le modèle de la session principale ou le [secondary_model] de config.toml), override (qui permettrait à un fichier de projet de remplacer un subagent intégré), subagents, whenToUse, ni les clés maxTurns, version, updated et portability d'Apothem.

À savoir :

• Les fichiers de subagents sont des fichiers de projet ordinaires. Commitez-les avec le projet ou listez .kimi-code/agents/ dans .gitignore ; Apothem ne choisit pas à votre place.
• Kimi Code utilise un auxiliaire lorsque la délégation est demandée. Depuis sa version du 2026-10-25, il traite les tâches lui-même par défaut au lieu de lancer des subagents de sa propre initiative ; demandez donc un auxiliaire par son nom, dans un message ou dans AGENTS.md. La page de l'éditeur sur les subagents personnalisés décrit encore une planification automatique ; cela peut donc changer.
• Un fichier de niveau projet dans .kimi-code/agents/ a priorité sur une définition du même nom aux niveaux extra, utilisateur et plugin. Donnez à vos propres auxiliaires des noms différents de ceux d'Apothem. Le code de Kimi Code lit aussi .kimi-code/agents/ avant le dossier partagé .agents/agents/, qu'Apothem n'écrit jamais, et conserve le premier de deux fichiers du même nom ; la documentation ne le dit pas.
• Un fichier à vous portant le nom d'un auxiliaire Apothem est enregistré sous ~/.apothem/backups/ puis remplacé. La désinstallation ne le remet pas en place. Les fichiers portant d'autres noms ne sont jamais touchés.
• Les versions antérieures conservaient les fichiers d'auxiliaires dans l'arborescence de support, à .kimi-code/.apothem/support/agents/, où Kimi Code ne les chargeait pas. Un apothem update ou un apothem uninstall supprime cette copie après l'avoir enregistrée sous ~/.apothem/backups/.

Correspondance entre le profil et la configuration nativeCopy Anchor Link

L'adaptateur lit le profil partagé d'Apothem et rend la surface d'instructions AGENTS.md à la racine du projet à chaque exécution de apothem install ou de apothem update. Les règles comportementales et le corpus de gouvernance atterrissent dans le bloc géré de AGENTS.md. Chaque skill, et chaque commande enveloppée en skill, atterrit à .kimi-code/skills/<name>/SKILL.md, un répertoire de skills de projet que Kimi Code charge. L'adaptateur n'écrit que ce dossier propre à Kimi et jamais .agents/skills/, que d'autres outils lisent aussi. Les skills que vous ajoutez vous-même à .kimi-code/skills/ sous d'autres noms sont conservés lors de l'installation, de la mise à jour et de la désinstallation. Un skill qui s'y trouve sous le même nom qu'un skill Apothem est remplacé : l'installation et la mise à jour l'écrasent, et la désinstallation le supprime, chaque fois après une copie horodatée sous ~/.apothem/backups/, et l'installation n'affiche aucun avis de la collision. Donnez à vos propres skills des noms différents de ceux d'Apothem.

Les cohortes de hooks, de règles et de templates sont placées sous .kimi-code/.apothem/support/ et référencées depuis la surface d'instructions. Kimi Code ne les charge pas depuis l'arborescence de support ; les copies Apothem qui s'y trouvent sont donc du matériel de référence vers lequel pointe le bloc AGENTS.md. Le bloc se termine par une section consacrée aux fichiers de support Apothem, qui nomme, relativement à la racine du projet, le répertoire sous .kimi-code/.apothem/support/ par rapport auquel se résout chaque citation de style dépôt (rules/<name>.md, templates/..., hooks/...), de sorte qu'un AGENTS.md commité ne porte aucun chemin propre à une machine. (Comportement de Kimi Code selon ses pages de personnalisation consacrées aux skills, aux définitions d'auxiliaires et aux hooks, consultées le 2026-10-24 pour les skills et les hooks, et le 2026-10-27 pour les définitions d'auxiliaires.)

Non installé nativementCopy Anchor Link

Kimi Code documente un emplacement natif pour les hooks. L'adaptateur n'y écrit pas encore, pour les raisons suivantes.

• Hooks. Kimi Code lit les hooks depuis le tableau [[hooks]] de ~/.kimi-code/config.toml ($KIMI_CODE_HOME/config.toml lorsque cette variable est définie). Apothem n'en écrit aucun. Ce fichier est de portée utilisateur alors que cet adaptateur écrit sous la racine du projet ; une entrée n'autorise que quatre champs (event et command obligatoires, matcher et timeout optionnels) et un champ supplémentaire empêche la configuration de se charger ; et Apothem n'a aucune fusion TOML qui pourrait plus tard ne supprimer que ses propres entrées. Les scripts auxiliaires des hooks restent dans l'arborescence de support.
• Frontmatter des skills. La page de l'éditeur documente les clés de SKILL.md name et description (toutes deux obligatoires), type, whenToUse, disableModelInvocation (aussi acceptée sous la forme disable-model-invocation) et arguments. Elle n'énonce aucune règle pour les autres clés. Les skills s'installent avec le frontmatter qu'ils ont dans la source Apothem ; des clés comme version, updated, archetype, userInvocable, argument-hint, portability et allowed-tools atteignent donc Kimi Code, qui peut les ignorer ou les rejeter.
• Skills du même nom. Kimi Code donne la priorité au niveau projet sur le niveau utilisateur ; un skill dans <project>/.kimi-code/skills/ l'emporte donc sur un skill du même nom dans ~/.agents/skills/, qu'écrit un autre adaptateur Apothem. La page de l'éditeur ne dit pas comment .kimi-code/skills/ et .agents/skills/ se classent l'un par rapport à l'autre au sein du niveau projet.

Notes de compatibilitéCopy Anchor Link

Kimi Code lit les instructions du projet depuis AGENTS.md ou .kimi-code/AGENTS.md et reconnaît .kimi-code/mcp.json comme la surface MCP détenue par l'opérateur ; Apothem nomme cette surface mais n'y rédige aucune entrée. Des deux fichiers d'instructions, l'adaptateur n'écrit que le AGENTS.md à la racine du projet, que Kimi Code lit comme instructions du projet ; la documentation de Kimi Code ne précise pas lequel des deux fichiers l'emporte lorsque les deux existent. Kimi Code n'expose aucune surface de fichier pour la ligne d'état ni pour les output-styles ; ces cohortes ne sont donc pas matérialisées.

Kimi Code s'exécute sur la famille de modèles Kimi de Moonshot ; consultez la référence de configuration de l'éditeur pour le modèle et la surface de configuration actuels.

VérificationCopy Anchor Link

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

La commande verify confirme que :

1. La configuration native existe au chemin attendu.
2. Chaque cible gérée existe, y compris les répertoires des skills et des subagents ; les fichiers gérés ne sont pas vides, et les configurations JSON ou YAML s'analysent correctement. Ajoutez --profile PATH pour vérifier en plus que les fichiers installés correspondent à ce profil. Pour .kimi-code/agents/, la vérification porte sur l'existence du dossier, et non sur la présence de chaque fichier d'auxiliaire ; la commande apothem diff --harness kimi-code --project /path/to/project liste les fichiers d'auxiliaires manquants ou obsolètes.
3. La routine de vérification propre à l'adaptateur signale un succès.

Mise à jourCopy Anchor Link

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

Redérive le bloc géré de AGENTS.md à la racine du projet, les skills, les fichiers de subagents et les cohortes de support à partir de l'état actuel du profil partagé. Une mise à jour d'une installation faite avant que les skills ne passent à .kimi-code/skills/ supprime l'ancien répertoire <project>/.kimi-code/.apothem/support/skills/, de sorte que chaque skill n'est présent qu'une fois. Une mise à jour d'une installation antérieure au passage des auxiliaires à .kimi-code/agents/ supprime de la même façon l'ancien répertoire <project>/.kimi-code/.apothem/support/agents/. Une copie horodatée de chaque répertoire supprimé est d'abord enregistrée sous ~/.apothem/backups/.

DésinstallationCopy Anchor Link

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

Retire le bloc Apothem du AGENTS.md à la racine du projet et conserve tout texte situé hors des sentinelles. Le fichier n'est supprimé que si plus rien d'autre n'y subsiste. Retire aussi les skills qu'Apothem a placés sous <project>/.kimi-code/skills/ (les skills que vous y avez ajoutés sous d'autres noms sont conservés), les fichiers de subagents sous <project>/.kimi-code/agents/ (les fichiers que vous y avez ajoutés sous d'autres noms sont conservés, et le dossier est supprimé lorsqu'il reste vide), et les fichiers de support sous <project>/.kimi-code/.apothem/support/, y compris les anciens répertoires skills/ et agents/ de l'arborescence de support d'une installation qui n'a jamais été mise à jour. Avant la modification, une copie horodatée de chaque fichier est enregistrée sous ~/.apothem/backups/ ; aucun fichier de sauvegarde n'est laissé dans le projet. Le YAML du profil partagé et le moteur Apothem ne sont pas affectés.

Portail de conformitéCopy Anchor Link

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

DépannageCopy Anchor Link

Paramètres de configurationCopy Anchor Link

Voir aussiCopy Anchor Link

• Tous les environnements — le catalogue complet des outils pris en charge
• Guide d'installation — installer Apothem dans cet environnement
• Référence de apothem harnesses — lister et inspecter les adaptateurs depuis la CLI