CLAUDE.md für Teams: Wie wir die KI-Erinnerungen von fünf Personen in gemeinsame Regeln umgewandelt haben

Jeder Entwickler, der mit einem KI-Programmierassistenten arbeitet, erstellt still und leise ein Regelwerk. Der automatische Speicher von Claude Code speichert während der Arbeit Notizen zu Ihren Korrekturen, Ihr persönliches Profil sammelt~/.claude/CLAUDE.md die Einstellungen, die Sie nicht mehr immer wieder neu eingeben möchten, und es entwickeln sich einige persönliche Fähigkeiten rund um die Aufgaben, die Sie jede Woche erledigen. All dies ist privat. Der automatische Speicher ist maschinenlokal und repo-spezifisch: Die Agenten Ihrer Teamkollegen haben keinen Zugriff darauf.

So lernen fünf Personen unabhängig voneinander dieselbe Lektion, jede in einer eigenen Datei. Die Regeln, die Ihr Team am dringendsten benötigt, sind bereits festgehalten. Sie sind lediglich nicht an einem gemeinsamen Ort festgehalten.

Im September führten wir zu fünft eine „Erinnerungssammlung“ durch: Wir legten diese privaten Aufzeichnungen zusammen und fragten uns, welche Regeln es verdienten, zu Teamregeln zu werden. So sind wir vorgegangen, welche Regeln den Sprung geschafft haben, wo jede Regel ihren Platz fand und was wir dabei festgestellt haben – einschließlich der Regeln, bei denen wir uns geirrt haben.

Was eine „Ernte der Erinnerungen“ ist

Eine „Memory Harvest“ ist eine Teamübung, die aus drei Schritten besteht. Jede Person exportiert ihre privaten Agenten-Erinnerungen und persönlichen Regeln. Ein Prüfer fasst die Einträge aus den Exporten aller Teilnehmer zu Clustern zusammen. Die Regeln, die mehrere Personen unabhängig voneinander notiert haben, werden für die gemeinsamen Dateien vorgeschlagen: das ProjektCLAUDE.md``AGENTS.md, eine gemeinsame Kompetenz oder einen Check-in in CI.

Es handelt sich um den Wartungsschritt, den das Context Engineering in der Regel überspringt. Wir haben bereits zuvor dargelegt, dass Kontextdateien eine Rückkopplungsschleife benötigen, die von den Agenten gesteuert wird, die sie nutzen. Eine „Harvest“-Aktion ist dieselbe Schleife, die jedoch nicht auf Sitzungen, sondern auf Personen angewendet wird: Es handelt sich um Phase 4 des Agenten-Feedback-Lebenszyklus, die auf die Notizen abzielt, die bereits im privaten Gedächtnis gestrandet sind.

Die entsprechenden Werkzeuge hierfür sind noch spärlich. Von zehn KI-Programmierwerkzeugen, die wir untersucht haben, bietet nur Devin eine Schleife, die eine Sitzung überwacht, eine gemeinsame Regel vorschlägt und darauf wartet, dass ein Mensch diese genehmigt. Die übrigen stützen sich auf Dateien, die von Nutzern manuell geschrieben und eingecheckt werden, oder auf Anweisungssätze, die ein Administrator bereitstellt. Keines dieser Tools wertet die persönlichen Erinnerungen mehrerer Personen aus, um mögliche Teamregeln zu ermitteln.

Was wir getan haben

Am 17. September 2026 führten fünf Entwickler jeweils ein Exportskript auf ihre eigenen Claude-Code-Speicher, ihre persönliche globale Variable undCLAUDE.md ihre persönlichen Fähigkeiten aus. Das Skript überträgt keinerlei Daten. Jede Person las ihr eigenes Datenbündel, löschte alles, was nicht übertragen werden sollte, und reichte es erst danach ein.

Die fünf Bündel enthielten 444 Speichereinträge, 5 globale CLAUDE.mdDateien, 13 persönliche Fähigkeiten und 194 Zeilen, die die in den einzelnen Repos installierten Fähigkeiten beschrieben. Ein Prüfer – ein KI-Agent, der mit einem Menschen zusammenarbeitete – gruppierte die Einträge über alle fünf Bündel hinweg und verfasste für jede Gruppe einen Vorschlag. Am 22. September stimmten vier von uns auf zwei Überprüfungsseiten ab. Die Beförderungen wurden als gewöhnliche Pull-Anfragen in drei Repos implementiert: unserem Hauptprodukt-Repo, einem Spiele-Repo und unserem gemeinsamen Skills-Plugin.

Die Bundles befinden sich auf einem Zweig, der niemals zusammengeführt wird. Nur die Promotions werden ausgegeben, jeweils als separater Pull-Request für das Repository, das sie betreffen, und wie jede andere Änderung geprüft.

Was zur Beförderung führt: Zählen Sie die Autoren, nicht die Beiträge

Eine Regel wird hochgestuft, wenn zwei oder mehr Personen sie unabhängig voneinander niedergeschrieben haben. Zählen Sie die einzelnen Autoren, niemals die Einträge. Diese eine Regel leistete den größten Teil der Arbeit, und es bedurfte dreier Verfeinerungen, bevor man sich darauf verlassen konnte.

Berücksichtigen Sie den Hauptnutzer. Ein Bündel umfasste 251 der 444 Einträge, verteilt auf 10 Repos. Alle anderen trugen 37 bis 68 Einträge aus 1 bis 4 Repos bei. Somit bedeutete „zwei Autoren“ in der Regel „unser intensivster Agent-Nutzer plus einer“, und ein Cluster ohne diesen intensiven Nutzer war seltener und stellte einen stärkeren Hinweis dar. Diese Cluster haben wir gesondert gekennzeichnet.

Eine Person entspricht einem Verfasser. Ein Entwickler, der Daten von zwei Rechnern exportiert hat. Das ist ein Verfasser. Wenn dieselbe Regel dreimal von derselben Person wiederholt wird, dient dies der Hervorhebung. Zur Bestätigung ist eine zweite Person erforderlich.

Gemeinsam genutzte Quellen sind nicht unabhängig voneinander. Die globalen DateienCLAUDE.md zweier Personen waren in ihren ersten vier Abschnitten byteweise identisch, da beide denselben veröffentlichten Text übernommen hatten: Andrej Karpathys Programmierrichtlinien für KI-Agenten. Beide zitierten ein und dasselbe übergeordnetes Dokument, sodass dies als eine einzige Quelle galt. Jeder zukünftige Cluster, der ausschließlich auf diesem Paar basiert, wird zunächst anhand des Wortlauts des übergeordneten Dokuments überprüft.

Zur Klassifizierung der einzelnen Cluster haben wir die vier Operatoren aus ExpeL übernommen, einer Forschungsmethode für Agenten, die Regeln aus Erfahrungen lernen: ADD – eine neue Regel hinzufügen, UPVOTE – eine Regel aus den gemeinsamen Dokumenten bestätigen, DOWNVOTE – eine Regel ablehnen, der die Beweislage widerspricht, EDIT – eine Regel bearbeiten, die zwar nahe am Ziel liegt, aber falsch ist. „Downvote“ und „Edit“ sind ebenso wichtig wie „Add“. Ein Harvest-Vorgang, der lediglich Regeln hinzufügen kann, verlängert Ihre Kontextdateien, ohne deren Richtigkeit zu verbessern.

Der Schwellenwert legt fest, was der Gutachter vorschlägt, nicht, was das Team möglicherweise annimmt. Auf einer zweiten Begutachtungsseite wurden die von einem einzelnen Autor verfassten Fakten aufgelistet, deren Veröffentlichung sinnvoll erschien, und die Anwesenden stimmten über jeden einzelnen ab. Sie wurden aufgenommen, weil die Anwesenden sie gelesen hatten und zustimmten.

Wo die einzelnen Regeln abgelegt werden sollten

Sich auf eine Regel zu einigen, ist bereits die halbe Entscheidung. Die andere Hälfte betrifft ihre Ebene: die Ebene, auf der sie tatsächlich gelesen und angewendet wird. (Unser Leitfadenkapitel darüber, wo eine Korrektur ansetzen sollte, behandelt diesen Ablauf ausführlich.) Für die gesammelten Regeln haben wir folgende Routing-Tabelle verwendet:

Die Regel lautet	Es gehört in	Warum
Eine unveränderliche Tatsache ist, dass jede Sitzung in diesem Repository Folgendes benötigt:	Das Projekt CLAUDE.md	Es wird zu Beginn jeder Sitzung geladen
Das Gleiche gilt für jedes KI-Tool, das das Team einsetzt	AGENTS.md, importiert aus CLAUDE.md	Eine Datei, die jedes Werkzeug lesen kann
Betrifft nur einen Teil des Quellcodes	Eine Regel mit Pfadgültigkeit in .claude/rules/	Wird nur geladen, wenn der Agent auf entsprechende Dateien stößt
Ein Verfahren, das in mehreren Repositories zum Einsatz kommt	Eine Funktion in einem gemeinsam genutzten Plugin	Plugins enthalten Fähigkeiten, nicht CLAUDE.md
Eine für ein Repo spezifische Prozedur	Eine Repo-Fähigkeit	Wird geladen, wenn die Aufgabe dies erfordert
Die Referenzangaben sind zu umfangreich, um sie bei jeder Sitzung anzugeben	Ein Dokument sowie ein einzeiliger Hinweis in CLAUDE.md	Ein Dokument, das nicht geladen wird, ist ein Dokument, das der Makler niemals liest
Mechanisch überprüfbar	Eine Lint-Regel, ein Test oder eine CI-Prüfung	Prose warnt; ein Scheck verhindert es
Was der Agent tut, beispielsweise Git-Befehle ausführen oder Prozesse beenden	Ein Hook in einem gemeinsam genutzten Plugin	CI erhält niemals Einblick in die Aktionen des Agenten; ein Hook unterbricht den Befehl
Eine Präferenz hinsichtlich Ihrer eigenen Werkzeuge, Maschinen oder Ihres Budgets	Ihre persönliche CLAUDE.mdoder Erinnerung	Dies ist keine Tatsache bezüglich des Quellcodes

Zwei Punkte müssen besonders hervorgehoben werden. Erstens: Ein „Claude Code“-Plugin kann Skills, Agenten und Hooks enthalten, jedoch keine ProzedurenCLAUDE.md. Prozeduren erstrecken sich über mehrere Repositories hinweg; allgemeine Regeln müssen in jedem Repository hinterlegt werden, in dem sie benötigt werden.

Zweitens: Löschen Sie den privaten Speicher erst, sobald das Zieldokument automatisch geladen wird. Wenn Sie eine Regel in ein Dokument verschieben, das nicht geladen wird, vergisst der Agent diese einfach. Wurde eine Regel in Referenzdokumente verschoben, schrumpfte der private Speicher auf einen Zeiger, anstatt vollständig zu verschwinden.

Wie geht man mit Widersprüchen um?

Die gesammelten Erinnerungen stimmen nicht überein. Lösen Sie Widersprüche nach Geltungsbereich auf, wo dies möglich ist, ersetzen Sie die veraltete Seite und legen Sie Meinungsverschiedenheiten hinsichtlich der Präferenz in einem expliziten, ungelösten Bereich ab.

Prüfen Sie zunächst den Geltungsbereich. Ein Widerspruch betraf die Frage, wie Abhängigkeiten in einer zweiten Arbeitskopie eines Repositorys eingerichtet werden sollten: Zwei Personen hatten gegensätzliche Regeln verfasst. Beide waren in ihrem jeweiligen Repository zutreffend. Eine spätere Änderung an einer gemeinsam genutzten Funktion hatte das Problem inzwischen für beide gelöst, und es stellte sich heraus, dass die Speicherung unseres intensivsten Nutzers veraltet war; daher sollte diese Regel ersetzt und nicht stillschweigend gelöscht werden.

Ersetzen Sie, überschreiben Sie niemals. Wenn sich eine gemeinsam genutzte Regel ändert, fügen Sie die neue Regel mit einem Datum hinzu und lassen Sie die alte lesbar, so wie ein Protokoll über eine Architekturentscheidung eine frühere Entscheidung ersetzt. Der nächste Prüfer kann so erkennen, was sich geändert hat und warum.

Behalten Sie einen ungelösten Punkt bei. Der zweite Widerspruch betraf die Frage, welches KI-Modell die Unteragenten verwenden sollten. Zwei Personen sprachen sich für ein Spitzenmodell für jeden Unteragenten aus; eine Person wählte die Modelle je nach Aufgabe aus. Die Abstimmung ergab zwei Stimmen für „diskutieren“ und zwei für „zustimmen“. Die Frage blieb bewusst ungelöst, da es darum geht, wie viel jede Person bereit ist, auf eigene Rechnung auszugeben, und nicht um eine Tatsache der Codebasis. Dies bleibt in den privaten Regeln jeder einzelnen Person verankert.

Was die Ernte zutage brachte

Fünfzehn Promotions wurden von der ersten Überprüfungsseite angenommen: elf für unser Hauptprodukt-Repo (von denen zwei auch für das Spiele-Repo galten), drei für das „Shared Skills“-Plugin und eine zur Behebung eines Fehlers im eigenen Exporter von „The Harvest“. Siebzehn weitere wurden von der zweiten Seite angenommen: Fakten mit einem einzigen Autor, deren Weitergabe die Gruppe einvernehmlich genehmigte, sowie zwei Cluster, die bei der ersten Zählung fälschlicherweise als Ein-Autor-Beiträge erfasst worden waren. Auf der zweiten Seite wurde ein Eintrag abgelehnt, drei wurden zur weiteren Diskussion oder zur Suche nach einem passenderen Ort zurückgestellt, und drei wurden zwar genehmigt, erfordern jedoch Code oder eine Funktion anstelle einer Dokumentationszeile. Die Modellfrage blieb offen.

Das am häufigsten wiederkehrende Thema betraf Kommentare. Drei Autoren, von denen einer dies viermal notiert hatte, stellten fest: Kommentare geben dauerhafte Fakten über den Code wieder; sie beschreiben niemals die Änderung selbst oder deren Entstehungsgeschichte. Ein Autor merkte an, dass Subagenten hierfür in der Regel verantwortlich sind.

Der umfassendste Punkt betraf die Beweisführung. Vier der fünf Autoren hatten eine Version des Grundsatzes „Erst überprüfen, dann behaupten; eine erfolglose Suche ist kein Beweis für das Nichtvorhandensein“ verfasst. Behauptungen von Gutachtern sind Hypothesen, und die Tatsache, dass ein Fehler nicht reproduziert werden kann, beweist nicht, dass er nicht auftreten kann. Dies kam einer gemeinsamen Hausregel des Teams am nächsten, und sie war nirgendwo schriftlich festgehalten.

Eine damit zusammenhängende Gruppe von Vorfällen, die von zwei Autoren beschrieben wurde, betraf einen veralteten Git-Status: einen lokalen Zweig, der weit hinter dem Remote-Zweig zurücklag, sowie eine Suche, die auf der Grundlage eines falschen Checkouts durchgeführt wurde. Jeder der fünf Vorfälle führte zu einer als sicher geltenden, falschen Behauptung, die ihren Weg in eine Commit-Meldung oder eine Pull-Request-Beschreibung fand.

Es wurden nicht nur fehlende Leitlinien, sondern auch fehlerhafte Leitlinien korrigiert. Bei drei Feststellungen handelte es sich um Aufforderungen zum „DOWNVOTE“ oder „EDIT“ bezüglich bereits vorhandener Leitlinien:

• In unseren gemeinsamen Richtlinien wurde den Bearbeitern mitgeteiltAGENTS.md, beilint:fix Änderungen an Lint-Regeln eine repo-weite Überprüfung durchzuführen. Drei Personen hatten unabhängig voneinander davor gewarnt: Das Repo ist in der Ausgangsversion nicht Lint-konform, sodass eine repo-weite Korrektur Ihren Diff unter irrelevanten Formatierungsänderungen begraben würde.
• Eine gemeinsam genutzte Funktion, die angeblich im Falle eines Fehlersgh pr edit auf die API zurückgreift. Sie schlägt jedoch nicht fehl: Sie gibt eine nicht schwerwiegende Meldung aus, beendet die Ausführung mit dem Status 0 und lässt den Pull-Request unverändert. Ein Fallback, der auf einen Fehler ausgerichtet ist, der niemals auftritt, wird niemals ausgeführt. Drei Autoren waren in drei Repositories auf dieses Problem gestoßen.
• In einer bestehenden Warnung in unserer Agent-Dokumentation wurde ein Datenbankfehler als „harmlos“ bezeichnet, da er sofort zu einem Fehler führt. Drei Personen waren bei drei verschiedenen Tabellen darauf gestoßen. In einem Fall hatte der Fehler die Überprüfung und die CI-Prüfung bestanden und führte erst zur Laufzeit zu einem Absturz.

Einige vereinbarte Regeln gehörten in eine automatische Prüfung. Die oben genannte Datenbankwarnung lässt sich automatisch überprüfen: Ein Test, der das Schema ausliest, würde die gesamte Klasse beenden, während die Dokumentation lediglich darauf hinweist. „Bearbeiten Sie die generierte Schemadatei niemals manuell“ wurde als zutreffend anerkannt und dennoch zurückgestellt, da eine textliche Anweisung nicht das geeignete Mittel zur Durchsetzung ist. Zwei weitere vereinbarte Punkte wurden bereits als Schritt-für-Schritt-Anleitungen verfasst, wodurch sie zu Fertigkeiten werden. Mehrere Punkte wurden aus der Abstimmung als Tickets statt als Dokumentation herausgenommen.

Eine Regel kann zwar zum Standardverhalten gehören, muss aber dennoch schriftlich festgehalten werden. Zwei Personen hatten unabhängig voneinander geschrieben: „Führen Sie niemals ein Commit oder einen Push durch, es sei denn, Sie werden dazu aufgefordert.“ Einer brachte es auf den Punkt: „Das Erstellen von Dateien ist keine Erlaubnis, diese zu committen.“ Jeder Mitarbeiter sollte sich ohnehin bereits so verhalten. Zwei Personen haben dies schriftlich festgehalten, weil es dennoch immer wieder vorkam – was ein Argument dafür ist, dies ausdrücklich festzuhalten.

Bei der Ernte wurde ein Fehler in der Ernte entdeckt. Jedes Bundle trug einen Versionsstempel, sodass die Überprüfung den Vergleich von Bundles verweigerte, die nach unterschiedlichen Erfassungsregeln erstellt worden waren. Der Stempel stammte aus der Version des Plugins, nicht aus der des Exporters. Alle fünf Bundles wurden mit byte-identischen Skripten erstellt und mit drei verschiedenen Versionen versehen. Die Sicherheitsabfrage würde bei einer tatsächlichen Regeländerung niemals ausgelöst werden, hingegen bei jeder nicht damit zusammenhängenden Plugin-Aktualisierung. Diese Korrektur war eine der fünfzehn.

Wie oft sollte man es ausführen?

Die erste Ernte ist die aufwendigste: monatelange private Notizen, die in einer einzigen, zeitlich begrenzten Sitzung gesichtet werden. Führen Sie danach bei regelmäßigen Team-Abstimmungen eine fünfminütige Schnellüberprüfung durch: Gibt es etwas Neues, das mehr als eine Person notiert hat?

Fünf Fehlermodi, die bei der Konstruktion zu berücksichtigen sind:

• Nur-Schreiben: Regeln werden übernommen, und niemand überprüft, ob sich das Verhalten des Agenten geändert hat.
• Veraltet und ohne Verantwortlichen: Eine gemeinsame Regel überdauert den Code, den sie beschreibt.
• „N=1“-Effekt: Die entschiedene Meinung einer einzelnen Person wird zur Teamregel, weil diese Person sie als Erste zu Papier gebracht hat.
• Ein Dokument, das vier Arten von Inhalten enthält: allgemeine Vorschriften, Verfahren, Referenzinformationen und historische Hintergründe in einer einzigen Datei, die niemand von Anfang bis Ende durchliest.
• So stark abstrahiert, dass sie nutzlos ist: Eine Regel, die so weit vom auslösenden Vorfall verallgemeinert wurde, dass sie dem Akteur keine Anweisung mehr gibt, wie er vorgehen soll.

Was wir beim nächsten Mal anders machen würden

Beim Vergleich unseres Verfahrens mit selbstlernenden Tools haben sich vier Lücken gezeigt. Wir werden für jede dieser Lücken vor dem nächsten Durchlauf eine Korrektur in die Ernte einarbeiten.

Regeln bezüglich der eigenen Aktionen des Agenten erfordern einen Hook. Zwei unserer Probleme betrafen das Verhalten des Agenten selbst und nicht die Vorgaben des Codes: Unteragenten, die in den falschen Zweig committen, und ein umfassender Prozessabbruch, der die Shell, in der der Agent lief, beendete. Beides wird von der CI nie erkannt. Ein Hook kann den Befehl vor seiner Ausführung stoppen, und ein gemeinsam genutztes Plugin überträgt ihn auf jeden Rechner, auf dem es installiert ist.

Eine Regel, die die Menschen immer wieder neu lernen müssen, funktioniert nicht. Dies ist der oben beschriebene „Write-Only“-Fehlermodus, und eine „Harvest“-Abfrage kann ihn messen. Wenn eine Regel beim letzten Mal hochgestuft wurde und die Nutzer sie danach dennoch in ihren privaten Speicher geschrieben haben, funktioniert die gemeinsam genutzte Zeile nicht. Das ist das Signal, sie aus dem Text herauszunehmen und in einen Hook oder eine Überprüfung zu verschieben.

Überprüfen Sie, ob eine Erinnerung noch zutreffend ist, bevor Sie sie hochstufen. Eine Erinnerung warnte vor einem aktiven Fehler, der bereits behoben worden war. Wäre sie hochgestuft worden, hätte sie allen eine falsche Warnung angezeigt. Alles, was eine Datei, eine Funktion oder einen Fehler nennt, wird zunächst mit dem aktuellen Code abgeglichen.

Eine Auswertung berücksichtigt nur das, was die Teilnehmer aufgeschrieben haben. Die Anzahl der Einträge lag zwischen 37 und 251 pro Person, was mehr darüber aussagt, wer Dinge aufschreibt, als darüber, wer auf Probleme stößt. Beim nächsten Mal kann jede Person zunächst ihren Agenten bitten, die Protokolle ihrer eigenen letzten Sitzungen zu lesen und die Korrekturen aufzulisten, an die sie sich nicht erinnern kann. Sie entscheidet selbst, welche davon gespeichert werden sollen. Die Protokolle bleiben aus dem gemeinsamen Bündel heraus.

Wir haben auch in Erwägung gezogen, einen Agenten die gesamte Aufgabe übernehmen zu lassen: Sitzungen zu beobachten, eigene Regeln zu erstellen und diese automatisch zu laden. Einige Tools funktionieren bereits auf diese Weise, und unsere Übersicht über die Rückkopplungsschleifen von Agenten enthält ein solches Beispiel. Das funktioniert gut für die Einrichtung einer einzelnen Person. Bei Regeln, auf die sich ein ganzes Team stützt, möchten wir jedoch weiterhin, dass die Mitarbeiter jede einzelne Regel lesen und darüber abstimmen.

Führen Sie einen von Hand aus

Sie benötigen keine speziellen Werkzeuge. Unser Export bestand aus einem kleinen Skript, doch jeder Schritt lässt sich auch manuell ausführen:

1. Privater Export. Jede Person kopiert ihren Auto-Memory-Ordner (in Claude Code: ~/.claude/projects/<project>/memory/), ihre ~/.claude/CLAUDE.mdsowie alle persönlichen Fähigkeiten in einen eigenen Ordner pro Person.
2. Bitte vor dem Weiterleiten bereinigen. Jede Person löscht alles, was nicht weitergegeben werden darf: Zugangsdaten, Kundendaten, alles, was einen namentlich genannten Kollegen betrifft. Nichts wird versendet, ohne dass der Verfasser es zuvor gelesen hat.
3. Nach Bedeutung gruppieren. Ein Prüfer – sei es ein Mensch oder ein Bot – fasst Einträge zusammen, die denselben Inhalt mit unterschiedlichen Worten wiedergeben, und hält fest, wer den jeweiligen Eintrag verfasst hat.
4. Zählen Sie die einzelnen Autoren. Zwei oder mehr unabhängige Autoren stellen einen Kandidaten dar. Fassen Sie die Rechner einer Person zusammen, lassen Sie gemeinsam genutzten Upstream-Text unberücksichtigt und notieren Sie, welche Cluster auch ohne Ihren aktivsten Nutzer bestehen bleiben.
5. Klassifizieren und weiterleiten. Weisen Sie jedem Kandidaten die Bezeichnung „ADD“, „UPVOTE“, „DOWNVOTE“ oder „EDIT“ zu und ordnen Sie ihm anschließend anhand der obigen Routing-Tabelle ein Ziel zu.
6. Führen Sie Widersprüche separat auf. Klären Sie diese, soweit möglich, anhand des Geltungsbereichs; lassen Sie den Rest ungeklärt und weisen Sie ausdrücklich darauf hin.
7. Lassen Sie die Anwesenden abstimmen. Tragen Sie die Vorschläge auf einer Seite und die Fakten eines einzelnen Verfassers auf einer zweiten Seite ein und treffen Sie gemeinsam eine Entscheidung.
8. Behandeln Sie jede Änderung als eigenständige PR gegenüber dem Repo, das sie betrifft. Halten Sie die Rohdatenbündel aus dem Hauptzweig fern.

Häufig gestellte Fragen

Was ist eine „Memory Harvest“?

Eine „Memory Harvest“ ist eine Teamübung für KI-Programmieragenten: Jeder Entwickler exportiert die Erinnerungen seines privaten Agenten sowie seine persönlichen Regeln; ein Prüfer fasst die Einträge aus den Exporten aller Beteiligten zu Clustern zusammen, und die Regeln, die mehrere Personen unabhängig voneinander verfasst haben, werden in gemeinsam genutzte Dateien wie oderCLAUDE.md übertragenAGENTS.md. Dies ist der Wartungsschritt auf Teamebene im Rahmen des Context Engineering.

Wie viele Personen müssen zustimmen, bevor eine Regel in CLAUDE.md aufgenommen wird?

Wir ziehen zwei oder mehr unabhängige Autoren heran. Zählen Sie dabei einzelne Personen, nicht Einträge: Eine Person, die eine Regel dreimal wiederholt oder Daten von zwei Rechnern exportiert, gilt weiterhin als ein Autor. Zwei Personen, die denselben veröffentlichten Text kopiert haben, gelten ebenfalls nicht als unabhängig. Der Schwellenwert legt fest, was vorgeschlagen wird; das Team stimmt jedoch weiterhin über jede Höherstufung ab.

Was gehört in ein Team – CLAUDE.md oder das persönliche Gedächtnis?

Es gilt grundsätzlich, dass alle Inhalte in diesem Repository zum Projekt gehörenCLAUDE.md, da es automatisch geladen wird. Vorgehensweisen gehören in den Bereich „Skills“, detaillierte Referenzinformationen in die Dokumentation mit einem Verweis, und alles, was eine Maschine überprüfen kann, gehört in eine Lint-Regel oder einen Test. Präferenzen bezüglich Ihrer eigenen Werkzeuge, Ihrer Maschine oder Ihres Budgets bleiben privat.

Sollten die Teamregeln in die Datei „CLAUDE.md“ oder in die Datei „AGENTS.md“ aufgenommen werden?

Regeln, die jedes KI-Tool befolgen sollte, werden hier eingefügtAGENTS.md; Claude-spezifische Anweisungen verbleiben hierCLAUDE.md. Claude Code kann AGENTS.mddirekt oder über einen Import@AGENTS.md gelesen werden, sodass eine einzige Datei für alle von Ihrem Team verwendeten Tools ausreicht.

Was tun Sie, wenn sich die Erinnerungen zweier Entwickler widersprechen?

Prüfen Sie zunächst den Umfang: In verschiedenen Repositories können beide Varianten zutreffen, und möglicherweise wurde das Problem durch einen späteren Tool-Wechsel bereits gelöst. Sollte eine der beiden Varianten veraltet sein, ersetzen Sie diese, anstatt sie zu überschreiben. Handelt es sich bei der Uneinigkeit eher um eine Präferenz als um eine Tatsache der Codebasis, lassen Sie die Angelegenheit ungelöst und behalten Sie die jeweiligen Regeln in den privaten Einstellungen der einzelnen Personen bei.

Wie oft sollte ein Team eine „Memory Harvest“ durchführen?

Führen Sie eine begrenzte Sitzung durch, um den Rückstand abzubauen, und führen Sie anschließend im Rahmen einer regelmäßigen Teamabstimmung eine fünfminütige „Standing Check“-Runde durch, um neue Kandidaten zu ermitteln. Die erste Runde ist die aufwendigste; danach sollte das Volumen gering sein.

Treffen Sie diese Entscheidung gemeinsam als Team

Bei einer „Memory Harvest“ entscheidet das Team, welche Regeln gemeinsam gelten; der Prüfer unterbreitet lediglich Vorschläge. Der Export, die Clusterbildung und die Zählung lassen sich vollständig automatisieren. Die Abstimmung hingegen kann und sollte nicht automatisiert werden. Welche Regeln für alle verbindlich sind, welche persönlich bleiben und welche Meinungsverschiedenheiten offen bleiben, entscheiden diejenigen, die damit leben müssen. Dies ist derselbe Punkt, den wir im Bericht „Exists, the Room Doesn’t“ hervorheben: Eine aggregierte Sichtweise ist erst dann sinnvoll, wenn die Personen, die für die Korrekturen verantwortlich sind, gemeinsam entscheiden.

Das ist eine Retrospektive mit unterschiedlichen Inputs. Als unsere KI-Agenten ihre eigenen Retrospektivpunkte einreichten, stammten die Erkenntnisse aus ihren Sitzungen. Dieses Mal stammten sie aus unseren eigenen privaten Notizen, und der Raum übernahm dieselbe Aufgabe: das Muster erkennen, die Ebene auswählen und jedem Punkt einen Verantwortlichen zuweisen. Falls Ihr Team bereits regelmäßige Retrospektiven durchführt, lässt sich eine „Memory Harvest“ gut als ein Tagesordnungspunkt einbauen. Die vollständige Vorgehensweise finden Sie in unserem Leitfaden zu Retrospektiven mit KI-Agenten.

Führen Sie eine eigene Ernte durch oder sind Sie der Meinung, dass unser Schwellenwert falsch ist? Teilen Sie uns dies bitte mit: ai-discussion@teamretro.com.