複数のAIコーディングエージェントを単一/複数コードベースで併用する際に使う `AGENTS.md` シードプロンプト (EstreGenesis)

 (github.com/SoliEstre)
1 ポイント 投稿者 soliestre 13 일 전 | 4件のコメント | WhatsAppで共有

1つのプロジェクトで

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Gemini (Antigravity)
  • Cline
  • Windsurf
  • Continue

のようなAIコーディングエージェントを、トークン分散（コスト最小化）目的で複数同時に回していると、
CLAUDE.md や .cursor/rules/、GEMINI.md がだんだん別々に管理されるようになります。
EstreGenesis は、その問題を解こうとして作られた AI Native ブートストラップ用シードプロンプトライブラリです。

https://github.com/SoliEstre/EstreGenesis

シードファイルを1つ、チャットの最初のメッセージとして

  • 内容をコピペして貼り付ける、
  • ローカルパスで渡す、
  • 添付として投げる、
  • チャットで説明して間接的にファイル位置を伝える、など

の形で渡すと、

エージェントが

  • 新規プロジェクトを AGENTS.md 単一の真実のソース + 各ツール別ブリッジファイル構成でブートストラップする、または
  • すでに散在したルールファイルがある既存プロジェクトを検査し、同じ構成へマイグレーションしてくれます。

深さに応じて 3-tier (Master / Lite / Compact) のいずれかを選んで使えます。

  • Lite がデフォルトです。
  • トークンを大量投入するスタイルであったり（Opus 4.7、GPT 5.5 などの上位モデルのみを使って品質重視）、
    低位モデル（Sonnet、Haiku）でより堅牢なハーネスを持たせたい場合は Master tier を使えばよいです。
  • 逆にシードの影響を極小化したい場合は Compact tier が向いています。

英語/韓国語ペアで提供されます。
2言語のシードは phase・migration・運用ガイドまで同一に管理されているため、バイリンガルチームなら両言語ペアを一緒に配置してもかまいません。

中核パターンは4つです。

  1. AGENTS.md SSoT + ツール別の薄いブリッジでルールのカオスを防ぐ。
  2. .agent/_coordination/ により同時編集の衝突を防ぐ。
  3. .agent/_lessons/ により3時間のデバッグを次のセッションでは30秒で済ませられるよう、再発を防ぐ。
  4. 重要な決定では Research → Report → Plan ループを強制し、調査ベースの堅牢な開発を主導する。

そして今回の v1.6.0 で追加されたのが、agent-time と human-time の推定ポリシーです。
AI はたいてい計画立案時に、人間の開発基準で見積もった期間を 5〜10× に膨らませて提示するため、
ブートストラップ Phase 0 の実行ペースモード選択で

  • Cautious 2〜4×
  • Proactive 5〜6×
  • Burst 6〜8×
  • Sprint 9〜10×

の中から先に決めておくと、
すべての見積もりをエージェント作業時間 + 人間レビュー時間 + 実経過期間に分けて報告する形になります。
プロジェクト進行中のモード変更も可能で、_lessons/ による実測補正もできます。

さらに重要な任意ポリシーの1つが、（FE/BE のような）各連携プロジェクト repo と、それらを統括する別の開発文書専用 repo を分離して運用するパターンです。

** Antigravity や GitHub Copilot などは作業フォルダ外のファイルへアクセスできないため、文書 repo 配下に各ソース repo を置き、そのフォルダを .gitignore に登録して git スコープを分離する形です。

こうすると .md 中心の文書 repo ができ、ソースが public repo であっても開発文書だけは private にして公開範囲を調整できるようになります。

特に Claude の Project でプロジェクトを作成し、この文書専用 repo をプロジェクトのファイルとして GitHub 連携で取り込んでプロジェクト知識につなげると、プロジェクト文書ベースのチャットはもちろん、ディープリサーチまで可能な設定になります。（repo push のたびに Project で更新ボタンを押し、同期完了を待つ必要があります。）
コーディングエージェントとディープリサーチ可能なエージェントを両方使いながら、ディープリサーチが必要な事項が出てきたらディープリサーチ依頼プロンプトを作ってもらい、Claude Project でディープリサーチを実行し、
その結果を文書 repo の /archive/<日付>_<トピック> に入れて IDE のエージェントにレビューと取りまとめを任せれば、プロジェクトの開発進行を高いレベルに引き上げる効果が期待できます。
それだけでなく、Claude Project のチャットで収益化や事業（法律、特許など）に関する助言も可能になるため、このパターンを推奨したいです。

この repo は、私の2つ目の本格的な AI Native プロジェクトを Antigravity + Claude Code + GitHub Copilot の3エージェント同時運用で進めながら、同じミスの繰り返しや不便だった点を改善して蓄積したノウハウを、シードとして整理したものです。
そのほか自分の別プロジェクトでも有用だった利用パターンを集め、スノーボールのように積み上げています。

また、必ずしもコーディングエージェントでなくても Hermes のようなエージェントに渡せば、自分に適した部分だけをうまく吸収して反映してくれるので、事実上の万能シードと見てもよいです。

参考までにライセンスは Apache 2.0 です。

フィードバック・issue・他のAIツール向けブリッジ提案を歓迎します。

関連記事

4件のコメント

 
kurthong 13 일 전

まず、良いプロジェクトのご紹介ありがとうございます。私も関心のある分野です。
パターンがうまく整理されていますね。本文を拝見して、2点気になったのでコメントします。
1つ目 - _lessons/ の累積コストです。lessons が100件から500件程度まで積み上がると、grep の後にファイルを通読するコストが比例して増えていくはずですが、AI Native プロジェクトではどの閾値あたりからタスク開始時の毎回のコストが負担になってきたのか、もし計測データがあればぜひ知りたいです。
v1.3 の RAG インデックス最適化セクションは、結局のところ Markdown メタデータなので、本質的な解決ではないように感じたためです。

2つ目 - マルチエージェントを同時運用する際、同じファイルがエージェント数ぶん重複して読み込まれる箇所です。3エージェント前提の設計ですが、それぞれのセッションで AGENTS.md + rules.md + architecture.md + STATE.md + lessons をすべて読むのであれば、トークン分散の目的がむしろ掛け算で増幅される箇所ではないでしょうか。この点をどのように解かれたのか、あるいは今後どう解くお考えなのか気になります。
 
soliestre 13 일 전

上の回答は、私がシードハーネスをエンジニアリングするときに実際にプロンプトで指示した内容について、私が確実に覚えている範囲で即答したもので、
具体的な lessons の蓄積への対処方法の詳細は、シードのビルド過程でエージェントが検討し、自律的にディテールを追加して反映した領域なので、（シードとして蒸留する前に作業していたプロジェクトで、すでに進んでいた部分です。）
私が直接答えるよりも、実際の構成をよく把握しているシードを取りまとめたエージェントに聞くのが適切だと思い、家に帰ってから上の質疑について意見を聞いてみました。

整理してくれた回答は次のとおりです:

  1. タグ grep — 作業コンテキストに関連するタグで絞って検索し、lessons 全体を通読するわけではない。
  2. _lessons/README.md インデックス — タイトル・タグ・要約1行で、grep の前に一次フィルタをかける。
  3. パターン昇格 — 繰り返し出てくる lessons は docs/troubleshooting/ に定着させ、50件超のインデックス用フォルダ ceiling で自然に抑制する。

Q2 も同じ文脈で:

  • concurrent 運用は トークン節約が目的ではなく、競合防止・rule drift 防止が主目的。

とのことです。

トークン分散が目的なら、私が上で例として挙げた方式がまさにそのパターンでしょう。
 
soliestre 13 일 전

現在作業していたプロジェクトを見返してみたところ、lessons は16個が最大でした。
また、影響パートと Severity を一緒にラベリングしているため、ある程度の蓄積には耐えられそうですが、
それ以上積み上がった場合にどうするかのプランは考えておく必要がありそうです。

私の場合、シードそのもののテストを別途回しているわけではなく、
デモレベルのプロジェクトで試すのではなく、実際に本格的に進行中のプロジェクトへ適用して使いながら磨いている状況なので、測定データは特に存在しません。
RAG インデックス最適化の部分は、現時点では Markdown 中心の開発ドキュメント repo を対象として、現在のレベルで適用しています。
(* Claude Project の開発ドキュメント repo 連携時の最適化を目的として適用した部分です。)

2つ目の点については、実質的にはリアルタイムでの同時運用を積極的に推奨しているわけではありません。
目的に応じて効果的なモデルを使うことを基本の前提としており、
それ以外でも、明らかに異なるパートを作業する場合には同時に利用できます。
たとえば Claude を PM パート担当として、まず作業分配のプランニングを進めた後、
Antigravity と Codex で FE/BE をそれぞれ同時に回し、
PM が結果を取りまとめて再び次のプランニングを行う、といった形です。

そして現時点では、私自身がトークンを節約しなければならない状況ではないため、マスターシードではすべて上位モデルで回している関係もあり、
トークンの分散については、各エージェントプラットフォームごとにコストパフォーマンスの高いプランを選び、追加の他プラットフォームについても同様にコストパフォーマンスの良いプランを契約して水平拡張する、という考え方で対応しています。
トークンを絶対的に節約することが目的であれば、現時点ではこのシードの使用を積極的におすすめすることはありません。
 
soliestre 13 일 전

参考までに、Claude Project のファイル（プロジェクト知識）の容量制限は約 10MB なので、repo は必ずテキスト中心である必要があります。
もちろん、一部ファイルの除外は Claude Project 側の UI で可能なので、フォルダで分かれている、または数が少ない程度であれば問題ないかもしれません。