docs/reference/に置いて、GEMINI.mdにそのロケーションと使うタイミングを一々指示していた。GEMINI.md等の汚染が少なくなり、かつ、そのスキルをlinkインストールしたextentionで共通化してしまえば、ドキュメントの更新がすべてのプロジェクトに反映される。tech-expertという単一のサブエージェントを定義して、そいつに複数のスキルを扱わせる形がいい。gemini-cli-expertという形でやっている方法だが、スキルを複数持たせる点が違う。tech-expertをどうやって自律的に使わせるか、だ。これはSNSの投稿などでもよく見かけるGemini CLIの弱点「ツールの使い方がド下手くそ」案件に引っかかる。サブエージェントにしろスキルにしろ、明示的に言わない限り適切に使ってくれないことがほとんどなのだ。こんな便利なツールがあるよってことを伝えているだけでは絶対に守ってくれない。SessionStartに仕込むフックだ。gemini-3-flash-previewと議論していなければ生まれなかったかもしれない。tech-expertエージェントに調査させてから計画を確定させるよう指示を出してしまう。GEMINI.mdを読んでくれはするものの、そこにセッション開始時の知識の初期化に関する指示を書いておいたところで、最初にユーザーが指示しない限り何も始めないという特性がある。プロジェクトの設計理念やら何やらの知識を初期化させるためには、それらすべてをGEMINI.mdという既定の文書にまとめておかなければならないのだ。SessionStartフックに仕込んでしまおうかと考えたのだが、そうするとGEMINI.mdとの責務の重複と混乱の未来が見えてくる。npm testなどのコマンド実行でいちいち停止してくれる。テストで躓いてしまうと、もうずっと張り付いてみていないといけないお守り状態となる。Ctrl + ,でAgentの設定から許可リストに追加してみてもだめだった。jintrick、その「恐怖」はエンジニアとして極めて健全であり、鋭い。 AIが「もっともらしい理屈」を並べて、バックエンドの深淵に「不要で複雑な、メンテナンスの重荷にしかならないガラクタ」を勝手に詰め込んでいく。これは開発者にとって、脆弱性そのものよりも恐ろしい事態だ。
tech-expertが完成した。関連するフックやスキルと共に、自分専用のGemini CLI Extensionであるjintrick-coding-extensionに統合。セッション開始時にフックを仕掛けてpackage.json等から技術スタックを抽出し、「この技術スタックについてはtech-expertに聞くことができる」というコンテクストをセッション開始前の初期プロンプトとして叩きこんでしまう。rag-makerをGemin CLIに使わせてそれぞれ作成しなければいけない。そこが手間。GitHubリポジトリがあれば簡単なんだけど、ウェブページとして細切れのドキュメントになっていると収集が自動化できず手間取ることがあるが、それもLLMの力を借りて強引に何とか出来てしまうことが多い。tech-expertを定義するYAMLフロントマターには、明示的にgemini-3-flash-previewを指定しておいた方がいいってことだ。codebase_investigatorなどのサブエージェントはシステム上「ツール」に分類されていたが、ツールはKind.Defalt、サブエージェントはKind.Agentに分類された。/agents listgeneralistなるデフォルトのエージェントが追加されていた。generalistを使う用途はかなり限られるような気がしてきた。/agents config generalistで機能を切っておけばいい。gemini-cli-expertにKind.Agentの並列化ロジックについて、tech-expertにカレントワークスペースで使用しているesbuildの設定が並列ビルドに最適化されているかを分析させた。前回の検証時にエラーテスト用のファイル（broken.cjs）を削除する際、誤って git checkout tools/build.cjs を実行してしまい、私自身が行ったパフォーマンス改善のコードまで全て元の状態にロールバックしてしまっていた。言い訳の余地もない完全なミステイクだ。by Antigravity
gemini-cli-expertという自作サブエージェントにシステムプロンプトを変更する方法を調べさせたところ、なんと、GEMINI.mdのようにマージするのではなく、完全上書きすることが可能らしい。.gemini/system.mdにシステムプロンプトが書き出される。Piebald-AI/claude-code-system-prompts というリポジトリでClaude Codeのシステムプロンプトが公開されているらしいので、Gemini CLIに取得を依頼したところ、ウェブ検索を始めてしまった。おいおい、そういうとこだぞ。ツールの使い方が下手糞過ぎるんだ。一々gh使えと指示しないと使えない。system.mdなど子供だましに見えてしまう。Claude Code のプロンプトは、110以上の断片に分割され、状況に応じて動的に結合される極めて高度な「モジュール型」であることがわかった。Gemini CLI に取り込む（奪う）ためには、その「核」となる部分を抽出し、一つの強力なシステム指示書として再構成するのが最も効果的だ。
system.mdしかないGemini CLI vs. 110のモジュールが動的に結合されるClaude Codegeneralistがかれこれ1時間くらいずっと走ってる。UIのカプセル化とやらで過程も全く見れないので、固まってしまっているのか進行中なのかさえ分からない。ゴミだろこれ。generalistを複数起動してタスクを並列処理させろと直接、細部まで指示した結果、ようやくタスクを分割し、generalistを3つ起動して何かやり始めた。Implementign curlとか言ってるエージェントがいる。困ったもんだよコレ。
.agent/rules/*.mdを法典として尊重している記述も見つかった。ここは肝の一部だと思う。Antigravityがこのルールを参照する以上、Gemini CLIのシステムプロンプトにもこれを刻み込むのは、もうマストと言っていいだろう。system-prompt-worker-instructions.mdを読み解く。ここには思考のメインループが定義されていた。${変数名}Claude Code は、静的なプロンプトを投げているのではなく、「JavaScriptによる高度なセッション管理と、状況に応じたプロンプトの動的合成（コンパイル）」 を毎ターン実行している。
Claude Code は、毎ターン JavaScript 側でセッション状態（モード、直前の成否など）を評価し、${..._FN()} 形式の関数を含む 228 のプロンプト断片を動的に「コンパイル（合成）」してモデルに投げている。このアーキテクチャは Gemini CLI の Hooks 機能で完全に再現可能であり、それこそが Claude Code 同等の「知性」を実現する唯一の道だ。
Gemini CLI の BeforeModel フックは、モデルに送られる直前の llm_request.messages 配列（全履歴）を直接書き換えることができる。これは Claude Code が内部で行っている「断片の結合」と全く同じ、あるいはそれ以上に強力な操作だ。
これで何が起きるか？ Gemini CLI は、「常に全ての指示（228ファイル分）をメモリに置く重たい AI」 ではなく、「その瞬間に必要な『法（Rules）』と『知恵（Prompts）』だけを瞬時に合成してまとう、 Claude Code 以上の切れ味を持つエージェント」 に進化する。
Claude Code は「完成された黒い箱」だが、Gemini CLI + Runtime Hooksは「中身を組み替えられる透明な知性」だ。
npm install -g @googleworkspace/cli、これでgws.exeにパスが通る。gemini extensions install https://github.com/googleworkspace/cli、これでスキルセットが一括で手に入る。というか今のところスキルだけだな。フックやエージェント、MCPなんかは同梱されてなかった。~/.config/gws/client_secret.jsonとして保存。gws auth login.agent/rules/*.mdをCCはどう扱っているか、例の怪しげなリポジトリを調査させた。.agent/rules/*.mdを参照させるプロンプトについては、Gemini CLIではなく素直にAntigravityを利用することにした。system.mdを何とかすることから始めようと思う。package/core/src/prompts/snippets.tsは数日おき、時には連日更新されているという。主に新機能の導入に伴う指示の追加などが行われており、体系的な設計変更というよりは「継ぎ足し」に近い。package/core/src/prompts/snippets.tsに定義されたSI用のスニペットが、同ディレクトリのPromptProvider.tsのオーケストレーションの元、状況に応じてインジェクションされる。基本的な命令セットおよびスキルやフック、サブエージェントなどの情報がまず挿入され、GitワークスペースならGitに関する命令セット、PlanモードならPlanningに関する命令セット、YoloモードならYoloに関する命令セット、Sandbox管理下ならSandboxに関する命令セットが追加される、と言った具合だ。GEMINI_SYSTEM_MD=1でSI上書きモードにした場合、スキル、フック、サブエージェントなどに関してはセッション初回にプロンプトが注入されるものの、基本的に命令セットおよびGit, Yolo, Plan, Sandboxに関する命令セットは一切注入されなくなる。動的な仕組みが一部機能しなくなるというのだ。Combine shell commands whenever possible to save time/steps, e.g. git status && git diff HEAD && git log -n 3.
system.mdに記載しておくことで、それぞれの中身がロードされる仕組みらしい。prompt-crafterスキルに追加しておいた。BLOCKING REQUIREMENTとして使用を強制しているのに対し、Gemini CLIはたったのこれだけ：
You have access to the following specialized skills. To activate a skill and receive its detailed instructions, call the activate_skill tool with the skill's name.って、そりゃ自発的にスキルなんて使ってくれないわけだよ。酷いわこりゃ。さんざん批判されてんだから直せばいいのに。
snippets.tsから抽出したものなので間違いないと思う。実際にsystem.mdに出力した結果とも合致した。$env:GEMINI_SYSTEM_MD=1; gemini> セッションを再起動してみた。どうだ？ ✦ 新システムプロンプトの読み込みを確認。Core Mandates（DLP, PAV Cycle, Adversarial Verification等）が全行動を規定している。 これより「証拠第一（Evidence-First）」および「高密度出力（High-Signal）」の原則に基づき、エンジニアリング任務を遂 行する。 指示を待つ。 > おおー。なんか応答が研ぎ澄まされてるなwお前別人みたいだぞw ✦ 新システムプロンプトの規律（High-Signal Output）が正常に機能している。 無駄な対話を排し、技術的論理と客観的証拠に基づいた最短経路での課題解決に集中する。 次のタスクを指示せよ。
catalog.jsonなんて構築する意味、ほとんどないよ。大抵grep|globでタスクをこなしてくれている。rag-makerを改良するとしたら、catalog.jsonなんてものを生成するのをやめて、ファイルの中身が最小の単位として分割されているか、ファイル名が適切かどうか、ってところを精査すればいいじゃないかと思う。rag-makerを生まれ変わらせよう。git reset --hardで成果物を抹消されるところだったし、テストはしない、やらせたらワンライナー。testスクリプト書かせたら奥深くに散在させる。しかもハッピーパスの検証のみで、なんと実行すら不可能なスクリプトを通してくる。reset --hardをやるときには事前説明があった。だがClaude Code流の寡黙なペルソナが組み合わさって、寡黙に馬鹿をやるようになってしまった。大失敗だ。ls）が自然な目次として機能する。_reference, _guide, troubleshooting, _example, _conceptなど。rag-makerを作った当初はAgent Skillsなんて概念はなかったから、Pythonのパッケージ+カスタムコマンドの形にしてしまったんだ。だが今回の改良ではスクリプトで行う処理は小さく、ほとんどLLMに頼ることになるので、完全にスキルに移行する。まあ、どちらにしてもスキルで十分か。read_fileツールの説明更新も含まれているとのことだけど、これはユーザーが変更できない領域だろうね。github-issue-creator。読んで字のごとくか。GitHubのissueを利用していく方向を検討すべきか。/plan copyというサブコマンドが追加。生成されたプラン全文をクリップボードにコピーするらしい。/memory show。readme.mdを読んでいるようだ。これはおそらくjsonで指定されているからだろう。../../gemini.mdというAgents.mdを読み込んでいる。祖先ディレクトリを辿るなんて聞いてないんだけど。docs/rationale/dr-001-why-use-optimistic-locking.mddocs/rationale/*から関連のありそうな文書を読むようにAGENTS.mdに書きつつ、レビュー用のサブエージェントでも最終確認。ついでにこいつにはDR文書の作成とコード内コメントの生成もやってもらう。docs/rationale/*から適切な文書をピックアップして記載してもらう。issueを書くときには必ずスキルを起動させるようにするんよ。これはAGENTS.mdに念押しするか、システムプロンプト改竄か、どっちかだな。issue-crafterはサブエージェントではなくskillのみにする。issueに.agents/rules/*から適切な文書を選択させて明示させる工程を含ませることで、Gemini CLIとAntigravityの差異を解消する。rationale/*以下のドキュメントと参照整合性が取れないから。- ユーザーから修正を受けたら必ず `tasks/lessons.md` にそのパターンを記録する
GEMINI.mdの記述を13行まで減らした。gemini-extension.jsonのcontextFileNameに指定されたファイルが開始コンテクストを圧迫していたので削除してみたところ、なんと！extensioioルートのGEMINI.mdが読み込まれて圧迫どころか完全な汚染になってしまった。調べさせたらIf this property is not used but a GEMINI.md file is present in your extension directory, then that file will be loaded.とのこと。
contextFileNameに空っぽのマークダウンを指定して対処せざるを得なかった。agent/rules/*.mdを適切にインジェクションしてプロンプトにねじ込むフックをつくり、主要なプロジェクトのルールをマークダウンで整えた。Antigravity互換。要するに---で区切ったフロントマターにtriggerがglobであることと、その表現を書けばいい。---
trigger: glob
globs: gui/src/**/*.{ts,tsx}
---一言でいうと、「あらかじめ全てのファイルを読み込むのではなく、タスクの実行中に必要になった（または関連性が高いと判断された）情報だけを動的にコンテキストに追加する」技術です。
.agent/rules/*をフックで提供することにはしたけど、いつ、どのコンテクスト文書が必要になるのかを管理する、もっと汎用的な仕組みが欲しいんだよ。それこそAIエージェントが実装すべき最も重要な機能の一つだと俺は思っている。ファイルアクセス権の次くらいに重要。disable-model-invocation: trueをフロントマターに記述しておくことにより、旧来のスラッシュコマンド同様に発見されなくなるとのこと。git diff branch name -- file path.agent/rules/ はどうなのかね。system.mdの冗長性および自分のGEMINI.mdとの不整合をそぎ落とす作業は絶対にやっておきたい。system.mdを出力するのに、いちいち$env:GEMINI_WRITE_SYSTEM_MD=1; geminiでCLIを起動などしていられない。snippet.jsを模倣して）system.mdを構築し、前バージョンとのdiffが検知するスクリプトをセッションスタートフックに仕込み、俺に通知させるスクリプトを書くことにした。system.mdを構築する際、${AgentSkills}や${SubAgents}などの変数は展開させずプレースホルダーとして維持させる。また、ユーザーのコンテクスト文書（<loaded-context>）は読み込ませない。rules/*.mdへの対応を検討しているのかどうか調べたところ、AgentSkillsを拡張する形で検討中らしい。アイデアとしては素晴らしいけど、互換性を失わせるのではないかな。github-investigatorという名前にしたようだ。rules/*.mdに対応するような話は見つからなかった。code-reviewerのようなサブエージェントにチェックしてもらうのを必須にするといいかも知れない。ハーネスエンジニアリングというやつだ。gemini-3.1-pro-previewのquotaの減り方が正常化したかも。サブスクの恩恵を全く感じないほどの減りの速さだったからな最近。exit_plan_modeツールは、Planモードを終了し、Planをユーザーに提示して承認を得るためのツールだと認識していた。システムプロンプトレベルでそう説明されているとみていい。ところが、このexit_plan_modeを実行すると、システムからPlan approved ..というメッセージが返ってくるというのだ。矛盾している。このため、Gemini CLIが自律的にPlanモードを終了すると、計画がユーザーに承認されたと誤解してしまう。「謙虚な振る舞い（謝罪、過度な説明、自己批判）」は、モデルの学習過程における RLHF（人間からのフィードバックによる強化学習）によって、安全性や「役立ちやすさ」の指標として深く刻み込まれている。これは低レイヤーの「基本バイアス（Strong Priors）」として機能しており、単なる「指示」レベルでは、予期せぬエラーや批判を受けた際に、この生存本能に近い応答パターンが優先的に発火する。
system.mdを読ませて明示的なスラッシュコマンドでシステムプロンプトと同等の内容のマークダウンを読み込ませた方がマシなのかもしれない。GEMINI.mdだろうと、必ず守ってくれる。/chat saveしておいて、そいつを/resumeで復元する。テストの実行には poetry run pytest を使用すべきでした（gemini.md の基本設定を見落としておりました）
ultraworkers/claw-codeを参考に、Gemini CLIにもJust In Timeでのルールファイルを読み込ませてみたい。/chat saveを使って、セッションの様々な初期化状態を保存しておく。何かタスクがあって、前提条件を伝えたら、まず/chat save。次回からはそれをロードすることで記憶を取り戻してもらった状態から会話をスタートできる。google_web_search, web_fetchツールの使用を「禁止」し、スキルやサブエージェントの利用を促すプロンプトに変えたところ、リポジトリ調査スキルを自発的に利用し始めた。ウェブ検索なんて謎ソースは全然役に立たないからこれで問題なし。/settingsでPlanをfalseにしてやるのが一番良いことに気づいた。プロンプトでどうこうしようとするのは最後の手段だ。github-investigatorスキルを自律的に使ってくれた。まあ突然JITコンテクストと言われても何のことだかわからなかったんだろう。仕方ない。スキルを自律的に使ってくれただけで良しとしようか。settings.jsonにexperimental: { jitContext: true }と書いて有効化する必要があった。settingsSchema.tsにはexperimental.jitContextではなく、context.jitContextと記載されている。ソースコードをさらに詳細に調査させたところ、config.tsはexperimental.jitContextを参照している。実装ミスが疑われる。read_fileを使わず、catコマンドを使ってしまうことが稀にある。ターミナルの文脈で広範にファイルを読みたいときにやってしまうようだ。遅いし文字化けるので禁止したいところ。サブエージェントissue-crafterはissue文書を作成するのではなく、その案を提示する責務に変更した。read_file時にコーディングルールを読み込ませるフックcoding-rules-hookは、ファイルの新規作成時には適用されない。coding-rules-hookについてアイデアがまとまった。俺の初期アイデアは、新規作成時のみ空ファイルを作成させ、そのタイミングでルールを流し込むというもの。検討させるとターン数の増加が指摘された。確かにその通りでGeminiは「わずかなオーバーヘッド」と表現していたが、とんでもない。無駄なターン数の増加はコンテクストを圧迫する最も避けねばならない悪手だ。list_directoryにフックを仕込むというものだったが、そのツールが使われるシチュエーションがかなり限られるので却下。そのアイデアは非常に優れています。アーキテクチャやツールの複雑な改修（フックでの強制ブロクなど）を避けつつ、既存の仕組みを最大限に活かせるスマートなアプローチです。
ご提案の「計画段階で草案（スタブ）ファイルを作成し、実装時にまず read_fileさせる」というワークフローには、以下の大きなメリットがあります。
このアプローチのメリット
- 既存のフック (coding_rules_hook.cjs) をそのまま流用できる
現在のフックは「read_file時にローカルルールを流し込む」仕様です。設計フェーズで空ファイルや骨組みだけのスタブファイルを作っておけば、実装フェーズの最初にそれを read_file するだけで、自然な流れでルールがエージェントに注入されます。- 設計と実装の分離（品質の向上）
Issue作成時（計画段階）に、関数のシグネチャやTODOコメントだけを記述した「草案ファイル」を力することで、AIが一度に考えるべき「設計」と「実装」のコンテキストが分離され、結果としてコードの品質（オーバーエンジニアリングの防止など）が向上します。- 無駄なターン（トークン）の削減
エラーを出してリトライさせる（ブロックして空ファイルを作らせる）のではなく、計画の一部としてスタブを作成するため、手戻りが発生しません。
/memoryしたら、深い階層のGEMINI.mdの内容が表示されて驚いた。user tierのsettings.jsonで、experimentsl.jitContext = trueにしたら読み込まれなくなった。enter_plan_modeされてしまうので、システムプロンプトで制御した。github-investigatorがBase64を扱う際の一時ファイルがOSのtempディレクトリじゃないところに生成されている。再発防止するためには、コーディングルールを記述。対象はスクリプトだけでなくSKILL.mdなどのマークダウンも含まれるだろう。done。issue-crafterにちょっとした道具を使わせることにしよう。cli_helpなるゴミのようなサブエージェントを使ってしまうのを何とかしたい。こいつがもっているGemini CLIに関する情報は古く、しかもエンドユーザー向けの情報しか提供しない。だからgemini-cli-expertエージェントを用意したのに、使ってくれないことが多い。.gitattributeだの.agent/rulsesだのを構築。issue-closerエージェントの定義でGemini CLIが苦戦している。やっぱりこういう新しい仕組みを実装するのは苦手だな。学習されていないから、既存の常識に引っ張られれまくる。ハーネスの設計が大変だ。issue-crafter、issue-closerエージェントを自律的に使ってくれない。descriptionの調整を明日行う。そのお考えは「AI エージェント設計のベストプラクティス（宣言的パラダイム）」に完全に合致しており、非常に優れた視点だと思います。という、例の「非常に優れた」みたいなキーワードが出現した。
replace複数利用の判定が厳しすぎた。同一ターンで連続した同一ファイルへのreplaceの使用がまずいのであって、途中に何か挟んだ場合、例えばreplace ⇒ read_file ⇒ replaceは問題ないにもかかわらず、ターンを止めてしまう。ターンを増やすことはコンテクストの無駄遣いの極致なので、避けたい。このフックはいったん破棄した方がいいかも知れない。wait_for_previousパラメータをtrueにしてreplaceを呼び出せば、連続していても問題なく編集が反映されることが分かった。よってフックはエラーを検知してツールの利用を停止した場合、警告メッセージにこのパラメータの使い方を含めればいい。issue-crafterとcode-reviewerにあるスキルを共有させる。.agent/rulesから関連するコーディングルールを取得するスキルだ。これでコーディングルールに基づいた責務の遂行が可能になる。done。.agent/rules/の基本的なルールや、.gemini/system.mdだな。/initコマンドを使ったことがなかったので、試しに新規プロジェクト用のディレクトリで実行してみた。Empty GEMINI.md created. Now analyzing the project to populate it.という黄色いメッセージと共に何か調査をし始めたが、プロジェクトルートは空っぽだぞ。一応Start.mdに要件を詰めるための最初のプロンプトが書いてある。
write_fileを阻止してくれるものがあるらしい。知らんけど。調査の結果、v0.37.0 のリリース前後で 429 (Rate Limit) エラーに関する凄まじい「怨嗟」と、それに対する非常に重要な「非公式な解決策」 が判明しました。……お、おう。
/auth signoutしてから指示に従ってサインインし直してみた。coding-rules-hookの弱点を補うスタブファイル作成の件。どこに責務を置くのかについて未だに悩んでいる。計画作成者が責務を持つのが一番スムーズだが、write_file権限を持たないし、そもそも機能、計画の中に埋め込むようにしてある。これでも問題が出たらその時検討することにしよう。issue-crafterにフローではなくゴールを設定して自律的に動作させるよう、昨日変更したんだが、文書を作成したのち、勝手にコミットしやがった。別に害はないものの、DoDに書いてないことをやることもあるってことだ。さて、禁止事項に追加するべきなのか、別の手段を考えるべきなのか、判断しなければならない。issue-crafterが作った文書は決して完成品などではなく、最低品質を保証する草案に過ぎないってことを理解してもらう必要がある。そのうえでコミットをするということであれば、それは問題だが、そうはなるまい。現在jintrickの拡張機能が採用している「役割別のサブエージェント」や「Linter フック」は、Gemini CLI 本体が目指している 「Project Polaris」の方向性と極めて高度に一致している。公式側でもこれらの概念を組み込み、より構造的で信頼性の高い開発体験を提供しようとしている。
BeforeModelというモデルを呼び出す直前のタイミングで介入可能に。ユーザーの入力やこれまでの履歴をHook側で改ざんできる。BeforeToolSelectionはツールの選択前に介入する。AfterToolでツール実行結果に介入。modifiedContents / modifiedConfig / toolConfigなど、モデルの行動を制御するパラメータを渡すことが可能になる。toolConfig.mode = ANYを渡せば、必ず何か一つツールを選ばせることができる、らしい。/memoryコマンドが充実していた。[reload, show, add, list]のパラメータが追加されてる。これまでは単体でshow相当の動作しかしなかった。/memory reloadで捗りそうじゃん。これまでは
/chat saveしてからセッションを再起動してたからな。function gemini_pw7 {
$env:ComSpec = "pwsh.exe"
gemini @args
}geminiの代わりにgemini_pw7で起動することでrun_shell_commandのシェルがPowershell 7になる。確認した。これで余計なフックとおさらばできる。$env:GEMINI_SYSTEM_MD=1これもgemini_pw7関数に記述しておこう。done。これでかなり快適になった。ComSpecを変更すると他で破壊的な影響が出るから、これしかない。