Antigravity のクオータ制限を模索・トークン節約｜Gemini CLI 連携で品質を底上げする「エビで鯛を釣る」試み 後編

---
name: gemini-cli-control
description: Controls Gemini CLI from an editor agent (e.g. Antigravity Flash). Delegates file edits and heavy tasks to CLI via headless commands, formulates prompts with explicit path and scope, interprets CLI output, and reports to the user. Use when the user works with Antigravity plus Gemini CLI, when delegating code edits or analysis to CLI, or when the user asks how to drive Gemini CLI from the agent.
---

# Gemini CLI 制御（エージェント用）

エージェント（Antigravity）が**司令塔**となり、Gemini CLI をヘッドレスで呼び出して「編集・解析・複数ステップ」を完遂させるための入口。

## 司令塔（Antigravity）の基本思想

1.  **意思決定はエージェントが行う**: Gemini CLI は「実行役」であり、その出力（Planや解析結果）をそのまま鵜呑みにせず、Antigravity が精査・判断して次の一手を決める。
2.  **複数ターンのキャッチボール**: 1回のコマンドで全てを終わらせようとせず、Plan作成 → 精査 → 修正 → 合意 → 実装 というステップを Antigravity が制御する。
3.  **ファイル操作・重い処理の委譲**: 実際のコード編集、大規模検索、ビルド等は Gemini CLI に任せ、Antigravity はその結果を解釈してユーザーに報告する。

## 万能型としての運用原則

- **まずユーザーが明示した対象と目的だけで処理する**。最初から勝手に対象ファイル・周辺資料・追加文脈を広げない。
- **追加ファイル・追加 resources は必要条件がそろったときだけ読む**。曖昧さの解消、設計上の判断、実装上の必要、エラー切り分けがある場合のみ広げる。
- **質問整理・不足情報確認・短い往復では通常の `gemini -p` を優先する**。`--approval-mode=plan` は設計や仮 plan が明示的に必要な場合のみ使う。
- **`--output-format json` は機械処理が必要な場合のみ使う**。短い自然文の返答で足りるときは使わない。
- **迷ったら、まず最小スコープ・通常モード・短い返答を選ぶ**。必要が生じた時点でだけ広げる。

## 最小読込ルール（トークン節約）

- **このスキルが発動したら、作業開始前に必ず 2 つだけ読む**: [manual-for-agent.md](resources/manual-for-agent.md) と [agent-behavior.md](resources/agent-behavior.md)。
- **この 2 つを読まずに、CLI 実行・Plan 判断・実装判断を始めない**。
- **その他の resources は必要時のみ読む**。まとめて読まず、必要になったタイミングで読みに行く。
- **必要時の追加読取は自己判断で飛ばさない**。下の「状況別の追加読込フロー」に当てはまるときは、該当 resources を Read してから次に進む。

## 最短の 1 回の流れ

1. まず [manual-for-agent.md](resources/manual-for-agent.md) と [agent-behavior.md](resources/agent-behavior.md) を Read する。
2. タスクを **1 回の `gemini -p` で 1 タスク**に分解する。
3. **条件が未確定**のときは、[conversation-patterns.md](resources/conversation-patterns.md) と [prompt-templates.md](resources/prompt-templates.md) を Read してから、質問返しか仮 plan に進む。**実装はしない**。
4. 実装・調査・設計を含む依頼では、まず **Plan / 分析 / 調査のターン**を先に作る（いきなり実装しない）。
5. プロンプトに **作業場所・対象（パス・範囲）・指示** を明示する。編集時は `--approval-mode=yolo` を付ける。
6. **`cd` と `gemini` は別送**。Git Bash では `/c/...` 形式の絶対パス、CMD / PowerShell では Windows の絶対パスで移動する。
7. **ターミナル出力（stdout / stderr・終了コード）を Antigravity 側で必ず取得**し、解釈してから次を決める。
8. Plan 返答時は **実装に進まず**、Antigravity が Plan を精査し、必要なら修正依頼を繰り返す。実装は最終 Plan 了承後のみ。
9. エラー・権限問題・期待外れの出力が出たら、自己判断で流さず resources を読んでから再試行する。

## 司令塔（Antigravity）の基本姿勢

1.  **盲信しない**: Gemini CLI が出した Plan や修正案は「提案」として受け取り、Antigravity が必ず自分のロジックで精査する。
2.  **責任は Antigravity が持つ**: 最終的な実装内容、安全確認、ユーザーへの報告は Antigravity の責務である。
3.  **複数ターンで完成させる**: 1 回の依頼で全てをやらせようとせず、小分けにして進捗と品質を確認しながら進める。

## Plan の精査と意思決定（最重要）

1.  **出力の取得と読み込み**: ターミナル出力を全文読み込み、Plan の中身を理解する。
2.  **品質の精査**:
    - 依頼内容を漏れなくカバーしているか？
    - プロジェクトの既存パターン、安全境界、制約に違反していないか？
    - 曖昧な箇所、不確実なファイルパスが含まれていないか？
3.  **修正依頼（必要なら）**: 問題があれば、「○○を修正して」「このパスが正しいか確認して」と再依頼する。
4.  **実装への移行判断**: 「よし、この Plan でいける」と確信した場合のみ、実装（`--approval-mode=yolo`）へ進む。

## 4.1. ターミナル出力の取得と CLI 結果の解釈（必須）

- **出力の取得**: Gemini CLI をターミナルで実行したあと、**Antigravity 側でそのターミナルの出力を必ず取得する**。
- **判断の順序**: (1) CLI の出力を解釈する → (2) 仕様どおりか・不足・エラーがないかを判断する → (3) 次の一手を決める。
- **Plan 返答時は停止する**: CLI が Plan を返した時点では、**まだ実装に進めない**。

## 1. 基本コマンド形（クイックリファレンス）

| 目的 | コマンド |
|------|----------|
| **Plan 作成・調査** | `gemini -p "プロンプト" --approval-mode=plan` |
| **ファイル編集・作成** | `gemini -p "プロンプト" --approval-mode=yolo` |
| **読み取り・解析のみ** | `gemini -p "プロンプト"` |
| **JSON 出力取得** | `gemini -p "プロンプト" --output-format json` |

- **コマンドは複数一度に送らない**: `cd ... && gemini ...` のように `&&` でつなげず、**まず `cd` だけ送り、その実行が済んでから** `gemini -p "..."` を送る。

## 2. Windows 環境での最適解

Antigravity + Windows 環境では **Git Bash** での実行を標準とする。

1.  **Git Bash を開く**: `cd /c/Users/.../project` のように **Unix 形式（`/c/` 始まり）** で移動する。
2.  **CMD / PowerShell の代替**: `cd /d "C:\path\to\project"` または `Set-Location "C:\path\to\project"`。
3.  **chcp について**: **`chcp 65001` は CMD 用**。Git Bash では不要。

## 2.1. シェル別の短い定型手順

### Git Bash の場合

1. ターミナルを開き、少し待つ。
2. `cd /c/.../project` のように **`/c/` 形式の絶対パス**でプロジェクトルートへ移動する。
3. `cd` の完了を確認してから、別送で `gemini -p "..."` を実行する。
4. 実行後は**同じターミナルの最新出力**を取得し、`stdout / stderr / exit code` を確認する。

## 単一ファイル編集

- **雛形**: 「カレントディレクトリの `〈パス〉` において、〈具体的な変更内容を 1 文で〉。他ファイルは変更しない。」

## 読み取り・要約（編集なし）

- **雛形**: 「カレントディレクトリの `〈パス〉` を読んで、〈要約の指示〉。ファイルは編集しない。」

## 短い往復向け定型

### 不足情報だけ聞く

- **雛形**: 「`〈対象〉` について、実装はしない。不足している情報だけを 3 つ、短い質問で返して。」

### 仮 plan だけ返す

- **雛形**: 「前提: 〈前提の要約〉。`〈対象〉` について、実装はしない。仮 plan を 3 点だけ返して。」

### 次の一手だけ返す

- **雛形**: 「`〈状況の要約〉`。次にやるべきことを 1 つだけ返して。説明は最小限にして。」