Gemini CLI
Adaptador de entorno de Apothem para Gemini CLI (GA).
Proveedor: Google
Nombre de instalación: gemini-cli
Estado: GA
Configuración nativa: GEMINI.md y .gemini/ locales del proyecto
Instalación
apothem install --harness gemini-cli --project /path/to/projectEl adaptador tiene alcance de proyecto. Instala el GEMINI.md del proyecto,
convierte los comandos de Apothem en comandos de barra TOML de Gemini,
normaliza las definiciones de ayudantes locales y coloca las cohortes de
soporte no nativas bajo .gemini/.apothem/support/.
Otras herramientas de programación también leen el GEMINI.md de un proyecto,
así que el bloque de Apothem en él se escribe como guía para todo el proyecto
que no nombra ninguna herramienta concreta como su lector.
Archivos escritos:
GEMINI.md
.gemini/commands/*.toml
.gemini/agents/*.md
.gemini/skills/
.gemini/.apothem/support/Asignación del perfil a la configuración nativa
El adaptador lee las cohortes compartidas de Apothem y enruta cada una a través
de una superficie compatible con Gemini. Las reglas Markdown, las plantillas y
el material de hooks permanecen bajo .gemini/.apothem/support/ porque son
material de soporte, no un directorio de reglas nativo de Gemini.
El bloque de Apothem en GEMINI.md termina con una sección de archivos de
soporte de Apothem que nombra, de forma relativa a la raíz del proyecto, el
directorio bajo .gemini/.apothem/support/ contra el que se resuelve cada cita
con estilo de repositorio (rules/<name>.md, templates/..., hooks/...).
Las rutas son relativas para que un GEMINI.md incluido en un commit no lleve
ninguna ruta específica de una máquina.
Cada comando convertido en .gemini/commands/ contiene una description y un
prompt. El prompt contiene solo las instrucciones del comando; los metadatos
de Apothem al inicio del archivo de origen (versión, lista de herramientas y
campos similares) se omiten, de modo que el modelo nunca los lee como
instrucciones. Gemini ejecuta un comando personalizado solo cuando lo escribes.
Las definiciones de ayudantes en .gemini/agents/ conservan sus límites de
herramientas y su límite de turnos: la concesión tools de origen, menos
disallowedTools, se convierte en una lista de permitidos tools de Gemini
con nombres de herramientas de Gemini, y maxTurns se convierte en
max_turns. Por tanto, un ayudante de solo lectura no recibe ninguna
herramienta write_file ni replace. No se establece ningún modelo, así que
cada ayudante hereda el modelo de la sesión.
Un ayudante que la clave agent_mcp_servers del perfil lista también obtiene una
entrada mcp_<server>_* por cada servidor nombrado en su lista de permitidos
tools, de modo que puede llamar a las herramientas de ese servidor y a las de
ningún otro; sin la clave, cada ayudante conserva la lista de permitidos simple
(consulta
Servidores MCP).
Apothem escribe aquí una concesión solo para un nombre de servidor formado por
letras, dígitos y -, porque Gemini CLI no puede referirse a un nombre con
guion bajo; cualquier otro nombre se omite y se informa, y lo mismo ocurre con
una concesión para un ayudante que ya alcanza todos los servidores MCP.
Notas de compatibilidad
~/.gemini/ sigue siendo territorio con alcance de usuario para las
herramientas que usan un perfil global de Gemini. El adaptador de Gemini CLI
escribe únicamente en el proyecto pasado mediante --project.
Verificación
apothem verify --harness gemini-cli --project /path/to/projectEl comando verify confirma que:
- La configuración nativa existe en la ruta esperada.
- Cada destino gestionado existe; los archivos gestionados no están vacíos y
las configuraciones JSON o YAML se analizan correctamente. Añade
--profile PATHpara confirmar también que los archivos instalados coinciden con ese perfil. - La rutina de verificación específica del adaptador informa de éxito.
Actualización
apothem update --harness gemini-cli --project /path/to/projectRefresca GEMINI.md, los comandos convertidos, las definiciones de ayudantes
locales, las skills instaladas y el árbol de soporte
.gemini/.apothem/support/.
Desinstalación
apothem uninstall --harness gemini-cli --project /path/to/projectElimina el bloque de Apothem de <project>/GEMINI.md y conserva cualquier otro
texto que haya en él. El archivo se elimina solo cuando no queda nada más en él.
También elimina los archivos de Apothem en <project>/.gemini/commands/,
<project>/.gemini/skills/, <project>/.gemini/agents/ y
<project>/.gemini/.apothem/support/; los demás archivos de esas carpetas
permanecen. Antes del cambio, se guarda bajo ~/.apothem/backups/ una copia con
marca de tiempo de cada archivo; no se deja ningún archivo de respaldo en el
proyecto. El YAML del perfil compartido y el motor de Apothem no se ven
afectados.
Puerta de conformidad
python -m apothem.conformity.gate --all .Solución de problemas
| Síntoma | Solución |
|---|---|
| No se encuentra el archivo de configuración | Vuelve a ejecutar apothem install --harness gemini-cli --project /path/to/project |
| La verificación falló | Ejecuta apothem update --harness gemini-cli --project /path/to/project y luego verifica de nuevo |
| Contenido de configuración inesperado | Revisa ~/.config/apothem/profile.yaml o --profile PATH y luego vuelve a ejecutar apothem update --harness gemini-cli --project /path/to/project |
Opciones de configuración
| Indicador | Predeterminado | Descripción |
|---|---|---|
--dry-run | false | Previsualiza la instalación sin escribir archivos. |
Véase también
- Todos los entornos — el catálogo completo de herramientas compatibles
- Guía de instalación — instala Apothem en este entorno
- Referencia de
apothem harnesses— lista e inspecciona adaptadores desde la CLI