Apothem vs raw Gemini CLI config

Gemini CLI reads a single GEMINI.md rules file. Apothem's gemini-cli adapter renders it from the shared profile. This page contrasts hand-maintaining that config against managing it with Apothem.

Effort comparisonCopy Anchor Link

What Apothem managesCopy Anchor Link

The gemini-cli adapter writes a sentinel-delimited Apothem block into <project>/GEMINI.md that carries project-wide guidance and points to Apothem's material. Rules, templates and hooks land as support files under <project>/.gemini/.apothem/support/, and commands, skills and agents land under <project>/.gemini/. Gemini CLI documents a hooks object in settings.json, which stays operator-owned, so the adapter registers no hook and guardrail intent is expressed in the rule prose rather than a tool-call interception point. Every change to the shared rules re-renders GEMINI.md on the next apothem update.

Migration pathCopy Anchor Link

1. Run apothem profile init to create the shared profile if you have not yet.
2. Move the rules from your existing GEMINI.md into the shared corpus.
3. Run apothem install --harness gemini-cli --project <path> to render and write GEMINI.md.
4. Run apothem verify --harness gemini-cli --project <path> to confirm the config landed.
5. Use apothem update --harness gemini-cli --project <path> for every later change.

Read nextCopy Anchor Link

• Gemini CLI adapter reference
• Comparison overview