比較
Apothem 対 Gemini CLI の手動設定
Gemini CLI の GEMINI.md ルールファイルを手作業で保守する場合と、Apothem の共有プロファイルからレンダリングする場合の比較。
Gemini CLI は単一の GEMINI.md ルールファイルを読み取ります。Apothem の
gemini-cli アダプターは、それを共有プロファイルからレンダリングします。このページ
では、その設定を手作業で保守する場合と、Apothem で管理する場合を対比します。
労力の比較
| タスク | 手作業の構成 | Apothem 管理 |
|---|---|---|
| ルールを書く | 1 つの GEMINI.md を手で編集 | レンダリング：プロジェクト全体のガイダンスは GEMINI.md に、ルールは .gemini/.apothem/support/ に配置 |
| ルールを他のハーネスと揃えて保つ | 手作業、ツールごと | apothem update で自動 |
| 構成をインストール・削除する | GEMINI.md を手で書き・削除 | apothem install / apothem uninstall |
| 構成が正しいか検証する | 手作業での確認 | apothem verify --harness gemini-cli --project <path> |
Apothem が管理するもの
gemini-cli アダプターは、プロジェクト全体のガイダンスを載せ、Apothem の素材を指す、センチネルで区切られた Apothem ブロックを <project>/GEMINI.md に書き込みます。ルール、テンプレート、フックは <project>/.gemini/.apothem/support/ の下にサポートファイルとして配置され、コマンド、スキル、エージェントは <project>/.gemini/ の下に配置されます。Gemini CLI は settings.json の hooks オブジェクトを文書化していますが、これはオペレーター所有のままであるため、アダプターはフックを登録せず、ガードレールの意図は、ツール呼び出しの傍受点ではなく、ルールの文章で表現されます。共有ルールへの変更はすべて、次回の apothem update で GEMINI.md を再レンダリングします。
移行パス
- まだ共有プロファイルを作成していなければ、
apothem profile initを実行して作成します。 - 既存の
GEMINI.mdのルールを、共有コーパスへ移します。 apothem install --harness gemini-cli --project <path>を実行して、GEMINI.mdをレンダリングし書き込みます。apothem verify --harness gemini-cli --project <path>を実行して、構成が配置されたことを確認します。- 以降の変更には毎回
apothem update --harness gemini-cli --project <path>を使います。