AGENTS.md-Seed-Prompt für den gemeinsamen Einsatz mehrerer AI-Coding-Agenten in einer einzelnen oder mehreren Codebases (EstreGenesis)

Wenn man in einem Projekt mehrere AI-Coding-Agenten wie

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

parallel betreibt, um Tokens zu verteilen und die Kosten zu minimieren, dann entwickeln sich
CLAUDE.md, .cursor/rules/ und GEMINI.md mit der Zeit oft auseinander.
EstreGenesis ist eine AI-Native-Bootstrap-Seed-Prompt-Bibliothek, die genau dieses Problem lösen soll.

https://github.com/SoliEstre/EstreGenesis

Wenn man eine Seed-Datei als erste Nachricht im Chat übergibt, etwa indem man

• den Inhalt kopiert und einfügt,
• einen lokalen Pfad angibt,
• sie als Anhang mitsendet oder
• den Speicherort indirekt im Chat beschreibt,

übernimmt der Agent dann

• das Bootstrapping eines neuen Projekts mit AGENTS.md als Single Source of Truth plus einer Bridge-Dateistruktur pro Tool oder
• die Prüfung eines bestehenden Projekts mit bereits verstreuten Regeldateien und die Migration in dieselbe Struktur.

Je nach gewünschter Tiefe kann man eines von drei Tiers wählen: 3-tier (Master / Lite / Compact).

• Lite ist der Standard.
• Wenn man stark auf Token setzt oder ausschließlich höherklassige Modelle wie Opus 4.7 oder GPT 5.5 für maximale Qualität verwendet, oder bei kleineren Modellen (Sonnet, Haiku) ein robusteres Harness möchte, empfiehlt sich das Master-Tier.
• Wenn der Einfluss des Seeds dagegen möglichst klein sein soll, ist das Compact-Tier passend.

Es wird als englisch/koreanisches Paar bereitgestellt.
Da die Seeds in beiden Sprachen bis hin zu Phasen, Migration und Betriebsleitfaden identisch gepflegt werden, können bilinguale Teams beide Sprachversionen parallel einsetzen.

Die vier Kernmuster sind:

1. AGENTS.md als SSoT plus schlanke Bridges pro Tool, um Regel-Chaos zu vermeiden.
2. .agent/_coordination/ zur Vermeidung von Konflikten bei gleichzeitiger Bearbeitung.
3. .agent/_lessons/, damit aus 3 Stunden Debugging in der nächsten Session 30 Sekunden werden und Wiederholungsfehler vermieden werden.
4. Wichtige Entscheidungen folgen einem erzwungenen Research → Report → Plan-Loop, um robuste, recherchierte Entwicklung zu fördern.

Neu hinzugekommen in v1.6.0 ist eine Richtlinie zur Schätzung von agent-time vs human-time.
Da AIs bei der Planung die Dauer meist nach menschlichen Entwicklermaßstäben um das 5- bis 10-Fache überschätzen, kann man bei der Auswahl des Ausführungstempos in Bootstrap Phase 0 vorab festlegen zwischen

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

Dann werden alle Schätzungen getrennt berichtet als Agenten-Arbeitszeit + menschliche Review-Zeit + tatsächliche verstrichene Kalenderzeit.
Ein Wechsel des Modus während des Projekts ist möglich, und über _lessons/ lassen sich die Werte anhand realer Messungen nachjustieren.

Eine weitere wichtige optionale Richtlinie ist das getrennte Betreiben von verknüpften Projekt-Repositories (z. B. FE/BE) und eines separaten Repositories ausschließlich für Entwicklungsdokumentation, das diese Projekte übergreifend steuert.

** Antigravity oder GitHub Copilot können nicht auf Dateien außerhalb des Arbeitsordners zugreifen. Daher werden die einzelnen Source-Repositories unterhalb des Dokumentations-Repositories abgelegt und dieser Ordner in .gitignore eingetragen, um den Git-Scope zu trennen.

So entsteht ein Dokumentations-Repository mit Schwerpunkt auf .md-Dateien. Selbst wenn der Source-Code in einem öffentlichen Repository liegt, können die Entwicklungsdokumente privat bleiben, sodass sich der Veröffentlichungsumfang gezielt steuern lässt.

Gerade in Claude Projects lässt sich dieses Muster gut nutzen: Man erstellt ein Projekt, bindet dieses reine Dokumentations-Repository über eine GitHub-Verknüpfung als Projektdateien ein und verknüpft es so mit dem Projektwissen. Dann sind nicht nur Chats auf Basis der Projektdokumente möglich, sondern auch Deep Research. (Nach jedem Repo-Push muss im Projekt auf „Aktualisieren“ geklickt und die Synchronisierung abgewartet werden.)
Wenn man sowohl Coding-Agenten als auch Agenten mit Deep-Research-Fähigkeiten nutzt, kann man bei Bedarf einen Prompt für einen Deep-Research-Auftrag anfordern, Deep Research im Claude Project ausführen lassen und das Ergebnis anschließend im Dokumentations-Repository unter /archive/<Datum>_<Thema> ablegen. Danach kann der Agent in der IDE die Ergebnisse prüfen und konsolidieren. Das kann den Entwicklungsfortschritt eines Projekts deutlich auf ein höheres Niveau heben.
Außerdem ermöglicht Claude Project-Chat auch Beratung zu Monetarisierung und geschäftlichen Themen wie Recht oder Patenten, weshalb ich dieses Muster besonders empfehle.

Dieses Repository ist mein zweites ernsthaftes AI-Native-Projekt. Dabei habe ich Antigravity + Claude Code + GitHub Copilot mit drei Agenten gleichzeitig betrieben, wiederkehrende Fehler und unbequeme Punkte laufend verbessert und das dabei gesammelte Know-how als Seed aufbereitet.
Auch aus meinen anderen Projekten sammle ich nützliche Nutzungsmuster und lasse den Schneeball weiter wachsen.

Und selbst wenn es kein Coding-Agent ist: Gibt man den Seed an einen Agenten wie Hermes, übernimmt er die für ihn passenden Teile und setzt sie sinnvoll um. Insofern kann man ihn praktisch als universellen Seed betrachten.

Die Lizenz ist übrigens Apache 2.0.

Feedback, Issues und Vorschläge für Bridges zu weiteren AI-Tools sind willkommen.

[kurthong]

Vielen Dank zunächst für die Vorstellung des guten Projekts. Das ist auch ein Bereich, der mich interessiert.
Sie haben die Muster gut strukturiert. Beim Lesen des Beitrags sind mir zwei Punkte aufgefallen, zu denen ich aus Neugier einen Kommentar hinterlasse.
Erstens – die kumulierten Kosten von _lessons/. Wenn sich dort etwa 100 bis über 500 lessons ansammeln, dürften die Kosten für grep und das anschließende vollständige Lesen der Dateien proportional steigen. Mich würde interessieren, ob Sie Messdaten dazu haben, ab welchem Schwellenwert in einem AI-Native-Projekt die Startkosten pro Task spürbar belastend wurden.
Ich frage, weil mir der Abschnitt zur Optimierung des RAG-Index in v1.3 am Ende wie Markdown-Metadaten erscheint und damit nicht wie eine grundlegende Lösung.

Zweitens – die Stelle, an der beim gleichzeitigen Betrieb mehrerer Agenten dieselbe Datei entsprechend der Anzahl der Agenten mehrfach geladen wird. Das Design basiert auf 3 Agenten, aber wenn in jeder einzelnen Session jeweils AGENTS.md + rules.md + architecture.md + STATE.md + lessons komplett gelesen werden, ist das dann nicht gerade die Stelle, an der sich das Ziel der Token-Verteilung eher vervielfacht? Mich würde interessieren, wie Sie diesen Punkt gelöst haben oder künftig lösen wollen.

[soliestre]

Die obige Antwort war eine spontane Erwiderung auf Grundlage dessen, woran ich mich sicher erinnern konnte, basierend auf Anweisungen, die ich beim Engineering des Seed-Harness selbst direkt per Prompt gegeben hatte,
die genaue Vorgehensweise beim fortlaufenden Sammeln konkreter lessons war jedoch ein Bereich, den der Agent im Seed-Build-Prozess selbst geprüft und mit zusätzlichen Details ergänzt und eingearbeitet hat (ein Teil, der bereits im Projekt vor der Destillation zum Seed vorangetrieben worden war).
Deshalb schien es mir richtiger, statt selbst direkt zu antworten, den Agenten zu fragen, der den tatsächlich gut verstandenen Seed zusammengeführt hat, also habe ich ihn nach meiner Rückkehr nach Hause um seine Einschätzung zu den obigen Fragen und Antworten gebeten.

Die von ihm zusammengefasste Antwort lautet wie folgt:

1. Tag-grep — die Suche wird über Tags eingegrenzt, die für den Arbeitskontext relevant sind; nicht das vollständige Durchlesen aller lessons.
2. _lessons/README.md-Index — erste Filterstufe vor dem grep anhand von Titel, Tags und einer einzeiligen Zusammenfassung.
3. Pattern-Promotion — wiederkehrende lessons werden in docs/troubleshooting/ verankert; die Obergrenze von mehr als 50 Einträgen pro Indexing-Ordner sorgt für eine natürliche Begrenzung.

Bei Q2 ist es im selben Kontext ebenfalls so:

• Der Hauptzweck des concurrent Betriebs ist nicht das Sparen von Tokens, sondern das Vermeiden von Konflikten und Rule Drift.

So wurde es erklärt.

Wenn das Ziel die Verteilung von Tokens ist, dann wäre die Methode, die ich oben als Beispiel genannt habe, genau das passende Muster.

[soliestre]

Ich habe die Projekte durchgesehen, an denen ich gerade gearbeitet habe, und 16 lessons waren dabei das Maximum.
Außerdem werden der Auswirkungsbereich und die Severity gemeinsam gelabelt, daher scheint eine gewisse Akkumulation verkraftbar zu sein,
aber für den Fall, dass sich darüber hinaus noch mehr ansammelt, sollte man wohl einen Plan dafür haben.

In meinem Fall führe ich keine separaten Tests für den Seed durch;
ich setze ihn nicht nur in Projekten auf Demo-Niveau ein, sondern wende ihn in tatsächlich laufenden, ernsthaften Projekten an und verfeinere ihn dabei, daher liegen dazu keine gesonderten Messdaten vor.
Der Teil zur Optimierung des RAG-Index ist derzeit auf ein Repository mit überwiegend in Markdown verfasster Entwicklungsdokumentation ausgerichtet und wird auf diesem Stand angewendet.
(* Dieser Teil wurde mit dem Ziel angewendet, die Anbindung eines Entwicklungsdokumentations-Repositorys in Claude Project zu optimieren.)

Was den zweiten Punkt betrifft, empfehle ich in der Praxis nicht unbedingt einen gleichzeitigen Betrieb in Echtzeit.
Die Grundannahme ist, je nach Ziel das jeweils effektive Modell zu verwenden,
und darüber hinaus kann man sie parallel einsetzen, wenn klar unterschiedliche Teile bearbeitet werden.
Zum Beispiel kann man zuerst mit Claude in der Rolle des PM die Verteilungsplanung der Aufgaben durchführen,
danach Antigravity und Codex jeweils parallel für FE und BE laufen lassen,
und anschließend sammelt der PM die Ergebnisse ein und erstellt die nächste Planung.

Außerdem bin ich derzeit nicht in einer Situation, in der ich Tokens sparen müsste, weshalb ich beim Master-Seed überall die höherwertigen Modelle verwende,
und die Verteilung der Tokens gehe ich so an, dass ich für jede Agentenplattform einen Plan mit gutem Preis-Leistungs-Verhältnis wähle und zusätzlich auch bei anderen Plattformen entsprechende Preis-Leistungs-Pläne abonniere, um horizontal zu skalieren.
Wenn das primäre Ziel darin besteht, Tokens absolut einzusparen, würde ich die Verwendung dieses Seeds zum jetzigen Zeitpunkt eher nicht empfehlen.

[soliestre]

Zur Referenz: Das Größenlimit für Dateien (Projektwissen) in Claude Project liegt bei etwa 10 MB, daher sollte das Repo unbedingt überwiegend aus Text bestehen.
Natürlich können einige Dateien auch über die UI von Claude Project ausgeschlossen werden, daher kann es in Ordnung sein, wenn sie in Ordnern getrennt sind oder es nur wenige davon gibt.