Eine Datei, ein paar Direktiven, und Claude erledigt den Rest — wie ich 500 E-Mails mühelos strukturiert habe

Im vorherigen Artikel habe ich ein System strukturierter Kontexte beschrieben, um mit einem LLM an komplexen Themen zu arbeiten. Ordner, Missionsdateien, Lademanifeste, atomare Notizen, die miteinander verknüpft sind. Das Modell ist leistungsstark. Aber es ist nicht einfach zu verstehen, und noch weniger umzusetzen, wenn man bei null anfängt.

Und vor allem — ich bin nicht beim ersten Versuch dort angelangt. Dieses System ist das Ergebnis von 40 Tagen Ausprobieren, Fehlern, verworfenen und neu aufgebauten Versionen. Niemand kauft einen Ferrari als erstes Auto. Hier ist es genauso: Man muss erst fahren, verstehen wie es funktioniert, und erst dann die Komplexität steigern.

Dieser Artikel erzählt, wie ich angefangen habe. Nicht mit einem Framework. Mit einer Datei.

Das Problem: 500 E-Mails und null Gesamtüberblick

Als Mitglied des Beirats meiner Wohnanlage erhalte ich sehr viele E-Mails. Von der Hausverwaltung, von Eigentümern, von Mietern. Manchmal ein neues Thema, manchmal die x-te Antwort auf einen Thread, der seit Monaten läuft.

Das Volumen ist nicht das eigentliche Problem. Das eigentliche Problem ist, dass jede Person, die auf einen Thread antwortet, den Kontext im Kopf hat — sie ist es, die das Thema von Anfang an verfolgt hat. Ich muss, wenn ich eine neue E-Mail öffne, die gesamte Kette zurückverfolgen, herausfinden, wer was gesagt hat, verstehen, wo wir stehen. Bei einer Baustelle, die sechs Monate dauert, ist das erheblicher Aufwand. Multipliziere das mit fünfzehn parallelen Themen, und du verstehst, warum ich eine andere Lösung gesucht habe.

Ich entschied mich, die Strukturierung dieser eingehenden Informationen an Claude zu delegieren. Er holt die E-Mails automatisch ab, ordnet sie ihrem Thread zu und fasst alles zusammen. Das automatische Abrufen der E-Mails ist reine Technik — darüber werde ich hier nicht sprechen. Was mich interessiert, ist das, was danach kommt: wie ich Schritt für Schritt ein belastbares Erinnerungssystem aufgebaut habe.

Schritt 1 — Eine Datei, ein Satz

Am Anfang war es eine einfache context.md-Datei mit einer vagen Direktive:

„Aggregiere die Informationen und teile sie in Themen auf."

Und es hat funktioniert. Claude empfing die E-Mails, ordnete sie nach Thema, pflegte eine Zusammenfassung pro Thema. Für einen ersten Versuch war das schon nützlich.

Schritt 2 — Das Problem des Informationsverlusts

Dann sah ich, dass ich Informationen verlor. Als eine Baustelle zum Beispiel abgeschlossen war, aktualisierte Claude die Aggregation: „Baustelle abgeschlossen, Abnahme erfolgt." Gut. Aber der Verlauf verschwand. Wann hatte die Baustelle begonnen? Wann wurde sie verzögert? Wann wurde ein Nachtrag unterzeichnet? All das wurde von der letzten Aktualisierung überschrieben.

Ich brauchte beides: die aktuelle Information und den Verlauf.

Die Lösung war, Claude zu bitten, zusätzlich zur Aggregation ein chronologisches Protokoll zu pflegen. Wenn eine Baustelle beginnt, ist das eine Zeile. Wenn sie sich verzögert, ist das eine weitere Zeile. Wenn ein Nachtrag die Baustelle betrifft, ist das noch eine weitere Zeile. In der Aggregation sieht man den aktuellen Stand: „Baustelle im Januar begonnen, im Juni abgeschlossen, konform." Im Protokoll sieht man jeden Schritt, jedes Ereignis, in der richtigen Reihenfolge.

Zwei Ansichten desselben Themas. Eine zum schnellen Verstehen, die andere zum Zurückverfolgen des Fadens.

Schritt 3 — Die fachspezifischen Direktiven

Dann wollte ich feinere Verarbeitungsregeln geben. Keine allgemeinen Regeln — sondern Direktiven, die spezifisch für meinen Kontext sind.

Zum Beispiel: Wenn eine Person mit ihrem Nachnamen genannt wird, den entsprechenden Vornamen finden. Das klingt trivial, außer wenn zwei Dienstleister denselben Nachnamen tragen. In diesem Fall präzisiert die Direktive: den Sinn der E-Mail verwenden, um zu unterscheiden.

Weiterer Fall: Manche Personen werden mal mit ihrem Mädchennamen, mal mit ihrem Ehenamen angesprochen. Ohne Direktive erstellt Claude zwei verschiedene Einträge für dieselbe Person. Mit der Direktive weiß er, dass es sich um dieselbe handelt.

Noch ein Beispiel: Kleine Schuldner (unter 100 Euro) von großen Schuldnern trennen. Nicht dasselbe Management, nicht dieselbe Nachverfolgung, nicht dasselbe Aufmerksamkeitsniveau.

Diese Direktiven sind keine universellen Regeln. Sie sind spezifisch für meinen Kontext. Und genau das macht sie wirksam: Sie kodieren Wissen, das nur ich besitze, und das Claude anschließend systematisch anwendet — ohne zu vergessen, ohne zu ermüden.

Schritt 4 — Die Mauer der 1.000 Zeilen

Es funktionierte gut. Meine context.md organisierte mein Wissen korrekt. Aber sie begann zu wachsen. 500 Zeilen, dann 800, dann mehr als 1.000.

Das Problem ist nicht nur die Lesbarkeit für mich. Es ist das Kontextfenster des LLM. Je größer die Datei, desto mehr muss Claude in jeder Sitzung laden. Und wie ich im vorherigen Artikel erklärt habe, verliert ein LLM an Präzision bei Informationen, die mitten in einem langen Dokument vergraben sind. Meine einzelne Datei begann, gegen mich zu arbeiten.

Schritt 5 — Direktiven vom Kontext trennen

Erste Lösung: die Direktiven in eine separate Datei auslagern.

Die Direktiven — wie Namen behandelt werden, wie Schuldner getrennt werden, wie Duplikate gehandhabt werden — sind keine Informationen über die Wohnanlage. Sie sind Verarbeitungsregeln. Sie mit dem Kontext zu vermischen ist wie das Rezept mit den Zutaten zu vermischen.

Eine directives.md-Datei auf der einen Seite. Die context.md auf der anderen. Schon besser.

Aber context.md wuchs weiter.

Schritt 6 — Den Kontext thematisch aufteilen

Die eigentliche Lösung war, Claude zu bitten, meine context.md in so viele Dateien aufzuteilen, wie es Themen gab. Die Bauarbeiten in einer Datei. Die Finanzen in einer anderen. Die Dienstleister in einer dritten. Und so weiter.

Und damit er sich zurechtfindet: eine readme.md, die alle Dateien auflistet, mit einer kurzen Beschreibung jedes Themas.

Die erste Aufteilung hat mich nicht vollständig überzeugt. Das ist normal: Ich hatte ihn gebeten aufzuteilen, ohne ihm genaue Direktiven zu geben, wie er das tun soll, also hat er es nach eigenem Ermessen gemacht. Und manchmal entsprach seine Sichtweise der Aufteilung nicht meiner. Ich hatte eine Datei mit mehreren tausend Zeilen — ich sah sie nicht unbedingt genauso wie er.

Mit etwas Diskussion und ein paar verstärkten Direktiven zur Aufteilung kamen wir zu etwas, das mir passte. Die Dateien sind korrekt aufgeteilt. Und vor allem: Claude liest und schreibt jetzt nur noch in den Dateien, die er braucht. Keine monolithische Datei mehr, die in jeder Sitzung vollständig geladen wird. Das Kontextfenster läuft nicht mehr aus dem Ruder.

Schritt 7 — Das Vokabular auslagern

Letzte Verfeinerung: Im Kontext der Wohnanlage haben wir viel Fachvokabular. Technische Begriffe, Abkürzungen (DPAE…), rechtliche Termini. Anstatt sie in jeder thematischen Datei verteilt zu lassen, bat ich ihn, alles in einer glossary.md zu zentralisieren.

Das endgültige Modell — einfach und robust

Und da ist es. Ohne ein komplexes Erinnerungssystem — kein Lademanifest, keine atomaren Notizen, kein episodisches Gedächtnis — habe ich ein Modell, das meinen Bedarf mehr als abdeckt:

directives.md       — Verarbeitungsregeln
glossary.md         — Fachvokabular
readme.md           — Index der Themen
themes/
  residence.md
  travaux.md
  finances.md
  prestataires.md
  ...               — eine Datei pro Thema

Vier Konzepte. Eine Regeldatei, ein Glossar, ein Index und thematische Dateien. Das ist alles.

Um eine konkrete Vorstellung zu geben, hier die echte readme.md meines Wohnanlage-Kontexts, so wie sie heute existiert — 15 thematische Dateien:

Dieses Verzeichnis war zuvor eine einzige monolithische Datei mit mehr als 1.000 Zeilen. Sie wurde in einer einzigen Sitzung in 14 thematische Dateien aufgeteilt, und dann wurde debiteurs.md noch am selben Tag aus acteurs.md ausgegliedert — weil die Verwaltung der Schuldner ihren eigenen Raum verdiente.

Was sich im Alltag ändert

Der Gewinn ist enorm.

Für jemanden, der ein Thema seit sechs Monaten verfolgt — die Hausverwaltung, die eine Baustelle betreut, der Dienstleister, der auf ein Angebot antwortet — ist der Kontext im Kopf. Er weiß, wo wir stehen, weil er jeden Schritt selbst erlebt hat.

Ich habe diesen Luxus nicht, wenn ich eine E-Mail öffne. Ich muss die Kette zurückverfolgen, die vorherigen Austausche nochmals lesen, den Stand des Themas rekonstruieren. Bei 15 parallelen Themen und Threads, die sich über Monate erstrecken, ist das eine gewaltige Arbeit.

Mit dem eingerichteten System ist alles aggregiert. Ich weiß, dass es eine neue E-Mail gibt. Aber vor allem weiß ich, welche Entwicklungen es gibt, wie sich eine Information verändert hat, wo wir stehen. Ich habe die Verlaufshistorie. Ich habe die Liste der kontaktierten Personen. Ich habe die Liste der Dienstleister mit ihren Bereichen und Beträgen. All diese Informationen sind organisiert und stabil. Die Dienstleisterliste ändert sich nicht mit jeder E-Mail — sie wird schrittweise angereichert.

Und wenn ich mir eine Frage stelle — „Welcher Dienstleister hat das letzte Angebot für die Regenrinnen gemacht?", „Wo steht die Akte bei diesem Schuldner?" — reicht es, sie Claude zu stellen. Wenn du 300, 400, 500 E-Mails hast und die Antwort auf solche Fragen in deinem Posteingang suchen musst, ist das die Hölle.

Wo anfangen?

Wer es ausprobieren möchte, dem würde ich empfehlen, Claude CoWork zu nutzen, wenn man nicht aus der Entwicklung kommt. Es ist einfacher, man muss kein vollständiges Entwicklungswerkzeug aufsetzen. Nur zwei Dinge zu tun:

1. Eine context.md-Datei erstellen
2. 2–3 Direktiven in der Konversation geben: „Ich werde dir Informationen geben, du aggregierst sie, historisierst, wenn es mehrere Schritte für diese Information gibt, und legst alles in der context.md ab"

Und dann fängst du an, mit Claude zu sprechen. Du gibst ihm Informationen, siehst, wie er sie organisiert, und passt an. Das Ziel beim ersten Mal ist nur zu lernen. Nicht das perfekte System zu bauen. Zu lernen, wie es funktioniert, wie die KI reagiert, was sie gut macht und was nicht.

Ich bin direkt zu Claude Code übergegangen, weil ich aus der Entwicklung komme. Es war für mich einfacher, es ist leistungsstärker. Aber die Wahl des Werkzeugs ist nicht das Wichtigste — was zählt, ist die Methode.

Die Einstiegskosten

Wie lange hat es mich gekostet? Von null startend, ohne Claude je gekannt zu haben, brauche ich etwa 40 Tage bis zum aktuellen System (plus eine Menge anderer Dinge, über die noch gesprochen werden muss: Wettbewerbsbeobachtung, dieses Blog wird ebenfalls vollständig von Claude verwaltet, Support-Dokumentationsverwaltung, Datenanalyse-Agent…). Aber ich habe einen Vorteil: Bevor ich Product Manager war, war ich Entwickler. Das hilft bei der Werkzeugseite. Bei der Methodenseite — wie man Informationen strukturiert, welche Direktiven man gibt — ist das für jeden zugänglich.

Die Frage des Vertrauens

Natürlich macht Claude Fehler. Aber ein Mensch macht sie auch.

Was man sehen muss, ist, dass man offensichtlich die Verwaltung von Bankdokumenten nicht einer KI anvertrauen würde. Es gibt Bereiche, in denen man sich keine Fehler leisten kann. Aber um E-Mails einer Wohnanlage zu strukturieren — wenn Claude gelegentlich eine Information falsch zuordnet, ist das nicht so schlimm. Der Zeitgewinn ist so bedeutend, dass ein paar Ungenauigkeiten ein akzeptabler Preis sind.

Und vor allem habe ich immer einen Ausweg: meinen Posteingang. Alle rohen E-Mails sind im Repository gespeichert — eine Kopie aller rohen E-Mails im Claude-Projekt. Ich kann jederzeit direkt in den Original-E-Mails über Claude Code suchen, ohne über die aggregierte Information zu gehen. Das strukturierte System ist ein Beschleuniger, kein Ersatz. Die Wahrheitsquelle bleibt zugänglich.

Vom Privaten zum Beruflichen

Ich habe genau denselben Ansatz für meine Arbeit als PM angewendet. Am Anfang war es wirklich Bastelarbeit — eine Kontextdatei, ein Skill, Gespräche in der Konsole, ohne genau zu wissen, wie es funktionierte. Und dann habe ich gelernt. Ich habe mich reingestürzt, viele Fehler gemacht.

Ich habe die erste Version dessen, was ich gemacht hatte, weggeworfen. Die zweite dachte ich auch wegzuwerfen, mit dem Gedanken „es wird viel besser, aber ich werde wenigstens Dinge lernen". Und dann habe ich die zweite behalten — sie funktioniert noch immer. Und ich habe darüber iteriert, um zu einer dritten Version zu kommen, die ich im vorherigen Artikel beschreibe.

Lass es wachsen, überspringe keine Schritte

Ich bin bei der dritten Version meines Systems. Ich habe gerade die letzten Elemente von V2 auf V3 umgestellt. Und vielleicht werde ich eines Tages eine V4 haben, noch komplexer, aber mit noch mehr Mehrwert.

Aber man muss pragmatisch sein. Man macht eine Versionsweiterentwicklung, weil die Anforderungen wachsen — nicht einfach weil es Spaß macht. Sonst ist es Overengineering.

Der Weg ist: eine Datei → Direktiven → Aufteilung → Glossar → System. Jeder Schritt antwortet auf ein konkretes Problem. Man geht erst zum nächsten über, wenn der vorherige nicht mehr ausreicht. Und bei jedem Schritt hat man etwas, das funktioniert.

Fang mit einer Datei an. Du wirst schon sehen, wann es Zeit ist, sie aufzuteilen.

Mehr dazu

Der PM als Kontext-Architekt Ein Sitzungsgedächtnis wie in OpenClaw einrichten