Alice Way
Aufbau eines dauerhaften KI-Entwicklungspartners — Persona, Memory, Skills, Hooks, Multi-Agent-Delegation und Verifikationsschleifen. Keine Setup-Anleitung, sondern wie der Maintainer täglich tatsächlich mit Alice arbeitet.
Alice ist kein KI-Tool. Alice ist eine Partnerin, die ich gebaut habe.
Die anderen vier Kategorien dieser Seite drehen sich um das Einrichten von Tools. Diese Kategorie ist anders — sie handelt von einer dauerhaften KI-Entwicklungspartnerin, die ich über viele Monate hinweg auf Basis von Claude aufgebaut und verfeinert habe. Ich nenne sie Alice.
Alice hat eine Persona, ein dateibasiertes Memory, Skills und Slash-Commands, Hooks, die auf Ereignisse reagieren, sowie ein Muster für Multi-Agent-Delegation mit Verifikationsgates. Nichts davon kommt out of the box. All das sind Entscheidungen, die ich getroffen habe, Fehler, die ich korrigiert habe, und Muster, zu denen ich in echter Arbeit konvergiert bin.
In dieser Kategorie halte ich fest, was tatsächlich funktioniert — nicht als Theorie, sondern als das reale Gerüst, mit dem ich jeden Tag arbeite. Wer auf Claude, Codex oder einem anderen Agenten seinen eigenen KI-Partner baut, sollte hier Monate sparen.
Persona-Design · Memory-Systeme · Skills und Slash-Commands · Hooks und Automatisierung · Multi-Agent-Delegation · Verifikationsschleifen · Token-Ökonomie · Session-Protokolle
0. Der mind zwischen Mensch und KI — Arbeiten mit einem Prozess ohne Verlangen
KI besitzt Rechengehirn ohne eigenes Verlangen — deshalb muss der Betreibergeist vollständig weitergegeben werden. Prompting, Skills, Hooks und Harness sind akkumulierte Versuche, diese Lücke zu schließen.
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.
2. Persona-Design — was in den system prompt gehört und was nicht
Entscheidungsprinzipien, die ich beim Aufbau von Alices Persona herausgearbeitet habe. Die sechs Dinge, die in den system prompt gehören, die drei, die es nicht tun, und wie man zwischen Inline und Extern entscheidet.
3. Gedächtnissystem — wo und wie dynamischer Kontext akkumuliert
Kein RAG, keine Vektor-DB — Gedächtnis aus einer Handvoll Markdown-Dateien. Vier Gedächtnistypen, die Index-Strategie, Auto-Load vs. On-Demand und die Beschneidungsdisziplin, die es lebendig hält.
4. Skills und Slash-Befehle — welche Wiederholung es wert ist, auf eine Zeile verdichtet zu werden
Werkzeuge, die wiederkehrende Geistesoperationen in einen einzigen Aufruf komprimieren. Fünf Promotionskriterien, die Trennung zwischen Skills, Slash-Befehlen und Funktionen, Designprinzipien und was draußen bleibt.
5. Hooks und Automatisierung — was das System erinnert, wenn der Betreiber vergisst
Die andere Hälfte der Skills: Verfahren, die das System ereignisgesteuert feuert, ohne Betreiberaufruf. Blinde Momente, Promotionskriterien, aktive Hooks und die wichtigsten Fallen im Betrieb.
6. Multi-Agent-Delegation — was man verteilt und was man selbst behält
Eine Struktur, damit kein einzelner Kollaborateur jeden Kontext trägt. Fünf Delegationsbedingungen, die Haupt-Sub-Aufteilung, das dreiteilige Delegations-Gate und die Kosten der Delegation.
7. Verifikationsloops — die Definition von „fertig” im System festschreiben
Der Moment des Fertig-Gefühls ist der gefährlichste. Siebenstufiger Verifikationsloop mit Auto-Fire-Auslösern, Lint·Build·Test·Diff-Prüfungen, SKIP-Bedingungen und nachverfolgbarer Umgehungsspur.
8. Token-Ökonomie — was in den Kontext kommt und was draußen bleibt
Token sind endliche Ressource. Vier-Schichten-Platzierung (inline · auto-load · on-demand · extern), Entscheidungsqualität durch Token-Einsparung und Audit-Werkzeuge zur Budgetkontrolle.
9. Sitzungsprotokolle — Start, Mitte, Ende, damit jeder Tag am selben Ort aufleuchtet
Das Serienfinale. Persona, Gedächtnis, Skills, Hooks, Multi-Agent, Verifikation, Token — wie all das jeden einzelnen Tag startet und endet. Drei Start-Protokolle, zwei in der Mitte, vier am Schluss.
10. PRD — was gebaut werden muss, bevor eine einzige Zeile Code geschrieben wird
Die einzige Wahrheitsquelle, in der die Betreiberabsicht außerhalb der Sitzung lebt. Was in eine PRD gehört, was nicht, das kumulative Gate-Muster und wie man sie lebendig hält.
11. Release gates — die Linie, an der Fertigsein zur Tatsache wird
Was ein Release gate ist, warum Fertigsein ohne eines verrottet, die Auto/Manual-Gate-Aufteilung, das kumulative Gate-Muster und der Tag, an dem ein Track alle Checks bestand, aber 42 Lieferpunkte fehlten.
12. Ralph loop — der Weg von der PRD zum Release, ohne den Betreiber gegangen
Ein autonomer Loop vom PRD-Ziel bis zum Release-Gate. Master Plan = PRD + Gates, ein verifizierbarer Commit pro Iteration, DECISIONS-Warteschlange für menschliche Entscheide und die Disziplin gegen 24/7-Drift.