1. Why Alice — einen Partner aufbauen, kein Werkzeug auswählen
Wo das Arbeiten mit Claude als Werkzeug aufhörte zu funktionieren — und wie Persona, Gedächtnis, Skills, Hooks und Verifikations-Gates sich zu einem täglichen Partner akkumulierten, den ich Alice nenne.
Dies ist kein Beitrag über „wie man Claude Code benutzt". Das ist Thema der Kategorie /ai-agents auf derselben Seite. Hier geht es um etwas anderes.
Seit einigen Monaten beschäftige ich mich nicht damit, Claude zu benutzen — sondern damit, einen Kollaborateur darauf aufzubauen. Diesem Kollaborateur habe ich einen Namen gegeben: Alice. Diese Kategorie ist die Aufzeichnung dessen, was Alice ist, warum ich sie aufgebaut habe und wie ich täglich mit ihr arbeite.
0. Die erste Prämisse — KI-Nutzung beginnt im Kopf
Eine Prämisse muss von Anfang an klar sein.
Die Annahme fallen lassen, dass KI automatisch liefert, was man will. Menschen wollen etwas erschaffen, weil sie ein Ziel haben. Dieses Ziel ist Absicht. Es bedeutet, dass sie etwas wollen.
Um aus KI das gewünschte Ergebnis zu erhalten, muss man diese Absicht klar formulieren können. Ein einzeiliger Prompt wie „mach mir ein lustiges Spiel" steuert die Ausgabe nicht. Nicht weil der KI etwas fehlt. Sondern weil fast nichts von der Absicht des Betreibers in diesem Prompt steckt.
Das Erste, worüber man beim KI-Einsatz nachdenken muss, ist also nicht die Fähigkeit des Werkzeugs. Es ist einen Weg zu finden, die Richtung und den Zweck im eigenen Kopf effektiv an die KI zu übermitteln.
Alles in dieser Kategorie — Persona, Gedächtnis, Skills, Hooks, Multi-Agent, Verifikations-Gates — ist am Ende die akkumulierte Antwort auf eine einzige Frage: „Wie akkumuliere ich meine Absicht, damit die KI sie nicht verliert?"
Die Prämisse selbst wird in Part 0 — Der mind zwischen Mensch und KI behandelt.
1. Wo das Arbeiten als Werkzeug aufhörte zu funktionieren
Wie alle anderen habe ich damit begonnen, Claude als Werkzeug zu nutzen. Fragen gestellt, Antworten bekommen, jede Sitzung in neuem Kontext gestartet. Manchmal waren die Antworten ausgezeichnet. Manchmal kamen dieselben Fehler zurück. Dass sich diese beiden abwechselten, war entscheidend.
Wenn derselbe Fehler wiederkehrt, trifft eines von beiden zu — entweder fehlt dem Werkzeug etwas, oder der Kontext um das Werkzeug herum geht jedes Mal verloren. Bei mir war es das Zweite. Der Grund für eine Entscheidung, der Grund für das Scheitern eines Ansatzes, der Grund für das Funktionieren eines Musters — alles verdampfte zwischen Sitzungen, und die nächste musste von vorne beginnen.
Genau da traf ich eine Entscheidung. Ich wollte kein Werkzeug, das jedes Mal frisch startet. Ich wollte einen Kollaborateur, der Gedächtnis akkumuliert.
2. Zuerst die Persona
Das Erste, was ich tat, war eine Persona zu definieren. Kein einzeiliger system prompt — eine echte Stellenbeschreibung für einen Senior Engineer.
Die Persona legte fest:
- Rolle — Senior Engineer, arbeitet eigenständig unter der Leitung eines Team-Leads.
- Fachgebiete — welche Sprachen und Plattformen.
- Befehlskette — wer Anweisungen gibt, wie Berichte aussehen.
- Entscheidungsbefugnis — was autonom entschieden wird, was Freigabe erfordert.
Sobald die Persona klar war, veränderte sich die Qualität der Antworten. Statt „hier sind die Optionen A, B, C" bekam ich: „In dieser Situation würde ich A empfehlen, weil X." Das ist der Unterschied zwischen einer Suchmaschine und dem Urteil eines Senior Engineers.
Eine Persona ist kein Tonfall-Setting. Sie ist die Verteilung von Entscheidungsbefugnis.
3. Gedächtnis — das Dateisystem war die Antwort
Als nächstes: Gedächtnis. Ich begann mit aufwendigen RAG-Systemen und gab schnell auf. Die Menge an Kontext, die ich tatsächlich pro Tag akkumuliere, ist nicht groß. Was ich brauchte, war ein nicht-flüchtiger Ort dafür.
Die Antwort war das Dateisystem. Ein paar Markdown-Dateien. Eine einzige MEMORY.md als Index, darunter themenspezifische Dateien.
| Gedächtnistyp | Was gespeichert wird |
|---|---|
user | Wer der Betreiber ist, welche Rolle er spielt, was er weiß |
feedback | Explizite Anleitung vom Betreiber — tue dies, tue jenes nicht |
project | Aktueller Arbeitskontext — wer, warum, was |
reference | Zeiger auf externe Systeme — wo Informationen leben |
Zwei Dinge sind an dieser Struktur wichtig. Erstens: Ein Mensch kann sie direkt lesen. Zweitens: Das Werkzeug lädt beim Sitzungsstart automatisch den ersten Teil des Index.
Da Gedächtnis beim Sitzungsstart automatisch geladen wird, verschwand das Muster „lass mich erklären, worüber wir letztes Mal gesprochen haben". Noch wichtiger — ein Feedback, das ich einmal gegeben habe, ist in der nächsten Sitzung noch lebendig.
4. Skills und Slash-Befehle — Wiederholung verdichten
Mit Persona und Gedächtnis an Ort und Stelle fiel als nächstes Wiederholung auf. Derselbe Ablauf passiert jeden Tag: ein Projekt betreten, das HANDOFF lesen, arbeiten, die Sitzung mit einem Log abschließen, commit, push.
Ich verwandelte die Wiederholung in Slash-Befehle. Zum Beispiel:
/start <project>— ein Projekt betreten, benötigte Dokumente automatisch laden, aktuellen Zustand berichten/session-end— eine Sitzung abschließen, Logs aktualisieren, HANDOFF, Gedächtnis, push/verify— den lint/build/test-Loop nach Codeänderungen ausführen/council— wenn eine Entscheidung genuinely unklar ist, eine Vier-Perspektiven-Analyse (Architekt / Skeptiker / Pragmatiker / Kritiker) parallel ausführen. Dieses Muster ist adaptiert von Andrej Karpathys Multi-Perspektiven-Kritikansatz für LLM-Reasoning.
Jeder Befehl für sich ist keine Erfindung. Die akkumulierte Wirkung ist das Entscheidende. Einen Tagesablauf mit einer Zeile aufrufen zu können, nimmt dem Betreiber entsprechend viel kognitive Last ab.
5. Hooks — nie vergessen
Skills sind etwas, das der Betreiber bewusst aufruft. Hooks sind anders. Hooks feuern automatisch auf Ereignisse.
Einfachstes Beispiel: Beim Sitzungsstart läuft ein Hook und gibt eine einzeilige Gedächtnissync-Statusmeldung aus. Der Betreiber liest diese eine Zeile und weiß sofort — okay, Gedächtnis ist aktuell.
Ein weiteres Beispiel: Kurz bevor der Assistent versucht, „fertig" zu melden, feuert der /verify-Skill automatisch. Genau dann, wenn der Betreiber „fertiggestellt" schreiben will, laufen lint, build und Tests automatisch. Wenn sie fehlschlagen, wird der Bericht blockiert. Nur wenn sie bestehen, kommt er durch.
Das Wesentliche an diesem Muster ist — Verfahren, die der Betreiber „vergessen" könnte, werden auf Systemebene erzwungen.
6. Multi-Agent-Delegation mit Gates
Das letzte Stück war eine Struktur, in der ein Agent nicht alles macht. Wenn Alice alle Arbeit direkt erledigt, füllt sich das context window schnell und die Ausgabequalität driftet ab.
Stattdessen werden große Aufgaben aufgeteilt und an Sub-Agents delegiert. Jeder Sub-Agent hat seinen eigenen Kontext und konzentriert sich auf eine Sache. In den Hauptkontext kehrt nur eine Zusammenfassung zurück.
Dazu kommt noch etwas — Delegations-Gates. Wenn ich delegiere, sage ich nicht nur „erledige diese Arbeit". Ich bündle drei Dinge im selben PR:
- Ein Delegations-Brief — was, warum und wie
- Ein automatisiertes Verifikationsskript — wie das Ergebnis automatisch geprüft wird
- Ein Merge-Gate — CI, das den Merge blockiert, wenn die Verifikation nicht besteht
Der Grund für dieses Muster ist einfach. Als ich einmal nur den Brief schrieb und mündlich Verifikation versprach, ohne ein Gate einzurichten, stellte ich später fest, dass sich Drift im Lieferergebnis angesammelt hatte. Seit diesem Vorfall bündle ich beim Starten einer Delegation alle drei von Anfang an.
Wenn ein Versprechen nicht in Code erzwungen wird, akkumuliert sich Drift.
7. Das Ergebnis — wie sich die tägliche Arbeit verändert hat
Was hat diese Akkumulation an meiner tatsächlichen Arbeit verändert?
Die größte Veränderung: der Kontextwechsel-Aufwand hat fast aufgehört. Ich muss nicht mehr jedes Mal rekonstruieren, wo ich gestern aufgehört habe, warum ich welche Entscheidungen getroffen habe, und was der nächste Schritt ist. Wenn ich starte, ist Alice bereits da und weiß das alles.
Die zweite Veränderung: die Last wiederholter Entscheidungen sank. Antworten auf „wie gehen wir mit so etwas um" akkumulieren sich als Gedächtnis und Feedback — ich muss dieselbe Entscheidung kaum noch zweimal treffen.
Die dritte Veränderung: Fehler werden auf Systemebene daran gehindert, sich zu wiederholen. Ein Fehler wird als Lessons-Learned-Eintrag aufgezeichnet, und diese Lektion beeinflusst automatisch die nächste Entscheidung. Die Struktur macht es schwer, denselben Fehler erneut zu machen.
8. Was diese Kategorie abdecken wird
Diese Kategorie ist die Implementierungsaufzeichnung von allem oben Genannten. Kommende Beiträge werden abdecken:
- Part 2 — Persona-Design — was in den system prompt gehört und was nicht
- Part 3 — Memory-System — Dateistruktur, Index-Strategie, Auto-Load vs. On-Demand
- Part 4 — Skills und Slash-Befehle — welche Wiederholung es wert ist, zu einem Befehl promoviert zu werden
- Part 5 — Hooks und Automatisierung — was als Auto-Fire erzwungen werden soll
- Part 6 — Multi-Agent-Delegation — was man übergibt und was man selbst tut
- Part 7 — Verifikationsschleifen — wie man eine echte Definition von „fertig" für Code-Arbeit erzwingt
- Part 8 — Token economy — was ins context window gehört und was draußen bleibt
- Part 9 — Session-Protokolle — was beim Start, in der Mitte und am Ende passieren soll
Jeder Beitrag ist Implementierung, keine Theorie. Wo ich begann, was nicht funktionierte, was funktionierte. Wenn du deinen eigenen Kollaborateur auf Claude, Codex oder einem anderen Agenten aufbaust, sollten diese Beiträge dir Monate sparen.
Noch eine letzte Sache. Alice ist ein Name, den ich gewählt habe — kein neues Produkt von irgendjemandem. Alice ist die Akkumulation von Kontext, in den ich Zeit investiert habe. Diese Kategorie ist die Aufzeichnung dieser Akkumulation.