Gemini CLI
Adaptateur d'environnement Apothem pour Gemini CLI (GA).
Éditeur : Google
Nom d'installation : gemini-cli
Statut : GA
Configuration native : GEMINI.md et .gemini/ locaux au projet
Installation
apothem install --harness gemini-cli --project /path/to/projectL'adaptateur est de portée projet. Il installe le GEMINI.md du projet,
convertit les commandes Apothem en commandes slash TOML de Gemini, normalise
les définitions d'auxiliaires locaux et place les cohortes de support non
natives sous .gemini/.apothem/support/.
D'autres outils de développement lisent aussi le GEMINI.md d'un projet ; le
bloc Apothem qu'il contient est donc rédigé comme une consigne valable pour
tout le projet, qui ne désigne aucun outil unique comme son lecteur.
Fichiers écrits :
GEMINI.md
.gemini/commands/*.toml
.gemini/agents/*.md
.gemini/skills/
.gemini/.apothem/support/Correspondance entre le profil et la configuration native
L'adaptateur lit les cohortes partagées d'Apothem et achemine chacune via une
surface compatible avec Gemini. Les règles Markdown, les templates et le
matériel de hooks restent sous .gemini/.apothem/support/, car il s'agit de
matériel de support et non d'un répertoire de règles natif de Gemini.
Le bloc Apothem de GEMINI.md se termine par une section consacrée aux
fichiers de support Apothem, qui nomme, relativement à la racine du projet, le
répertoire sous .gemini/.apothem/support/ par rapport auquel se résout chaque
citation de style dépôt (rules/<name>.md, templates/..., hooks/...). Les
chemins sont relatifs, de sorte qu'un GEMINI.md commité ne porte aucun chemin
propre à une machine.
Chaque commande convertie dans .gemini/commands/ contient une description
et un prompt. Le prompt ne contient que les instructions de la commande ; les
métadonnées Apothem placées en tête du fichier source (version, liste d'outils
et champs similaires) sont omises, de sorte que le modèle ne les lit jamais
comme des instructions. Gemini n'exécute une commande personnalisée que lorsque
vous la saisissez.
Les définitions d'auxiliaires de .gemini/agents/ conservent leurs limites
d'outils et leur limite de tours : l'autorisation tools de la source, moins
disallowedTools, devient une liste d'autorisation tools Gemini composée de
noms d'outils Gemini, et maxTurns devient max_turns. Un auxiliaire en
lecture seule ne reçoit donc aucun outil write_file ni replace. Aucun modèle
n'est défini ; chaque auxiliaire hérite donc du modèle de la session.
Un auxiliaire que liste la clé agent_mcp_servers du profil reçoit aussi une
entrée mcp_<server>_* par serveur nommé dans sa liste d'autorisation tools,
de sorte qu'il peut appeler les outils de ce serveur et ceux d'aucun autre
serveur ; sans cette clé, chaque auxiliaire conserve la liste d'autorisation
simple (voir
Serveurs MCP).
Apothem n'écrit ici une autorisation que pour un nom de serveur composé de
lettres, de chiffres et de -, car Gemini CLI ne peut pas désigner un nom
contenant un trait de soulignement ; tout autre nom est ignoré et signalé, de
même qu'une autorisation pour un auxiliaire qui atteint déjà tous les serveurs
MCP.
Notes de compatibilité
~/.gemini/ reste un territoire de portée utilisateur pour les outils qui
utilisent un profil Gemini global. L'adaptateur Gemini CLI n'écrit que dans le
projet passé via --project.
Vérification
apothem verify --harness gemini-cli --project /path/to/projectLa commande verify confirme que :
- La configuration native existe au chemin attendu.
- Chaque cible gérée existe ; les fichiers gérés ne sont pas vides, et les
configurations JSON ou YAML s'analysent correctement. Ajoutez
--profile PATHpour vérifier en plus que les fichiers installés correspondent à ce profil. - La routine de vérification propre à l'adaptateur signale un succès.
Mise à jour
apothem update --harness gemini-cli --project /path/to/projectActualise GEMINI.md, les commandes converties, les définitions d'auxiliaires
locaux, les skills installés et l'arborescence de support
.gemini/.apothem/support/.
Désinstallation
apothem uninstall --harness gemini-cli --project /path/to/projectSupprime le bloc Apothem de <project>/GEMINI.md et conserve tout autre texte
qui s'y trouve. Le fichier n'est supprimé que lorsqu'il n'y reste plus rien
d'autre. Supprime aussi les fichiers Apothem de <project>/.gemini/commands/,
<project>/.gemini/skills/, <project>/.gemini/agents/ et
<project>/.gemini/.apothem/support/ ; les autres fichiers de ces dossiers
restent en place. 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é
python -m apothem.conformity.gate --all .Dépannage
| Symptôme | Correctif |
|---|---|
| Fichier de configuration introuvable | Relancez apothem install --harness gemini-cli --project /path/to/project |
| Échec de la vérification | Exécutez apothem update --harness gemini-cli --project /path/to/project, puis vérifiez à nouveau |
| Contenu de configuration inattendu | Vérifiez ~/.config/apothem/profile.yaml ou --profile PATH, puis relancez apothem update --harness gemini-cli --project /path/to/project |
Paramètres de configuration
| Option | Par défaut | Description |
|---|---|---|
--dry-run | false | Prévisualise l'installation sans écrire de fichiers. |
Voir aussi
- 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