Im vorigen Artikel habe ich beschrieben, wie AI die Hürde senkt, Neues auszuprobieren. Am Ende stand ein Satz, den ich hier einlöse: Damit das auf Dauer trägt, braucht es eine Konstante – Kontext.
Das Problem kennt jeder, der mit mehreren Projekten und einem AI-Assistenten arbeitet: In jedem Repo erkläre ich aufs Neue, wie ich Dinge benenne, wie meine Layer-Architektur aussieht, warum ich diese eine Bibliothek bewusst nicht nutze. Die Entscheidungen sind längst getroffen. Aber sie leben in meinem Kopf, verteilt über Repos, und der Assistent kennt jeweils nur den Ausschnitt, den er gerade sieht.
Also habe ich angefangen, dieses Wissen an einen Ort zu legen, an dem sowohl ich als auch Claude es finden.
Warum Outline – und warum self-hosted
Die Wahl fiel auf Outline, self-hosted auf einer eigenen Subdomain. Drei Gründe gaben den Ausschlag.
Erstens: Ich will meine Daten bei mir behalten und nicht von einem Anbieter abhängig sein. Ein Wissensspeicher, in den über Jahre alle Entscheidungen fließen, ist genau die Art von Asset, das man nicht in fremder Hand wissen will.
Zweitens: voller Daten-Export, jederzeit. Wenn ich morgen auf ein anderes System umziehen will, nehme ich alles mit. Kein Lock-in, keine Geiselhaft.
Drittens: Self-hosted eröffnet später bessere Möglichkeiten – etwa für eigenes RAG, falls ich irgendwann tiefer in die Suche über den eigenen Wissensbestand einsteigen will. Aktuell brauche ich das nicht. Aber die Tür steht offen, und das ist mir den Aufwand wert.
Das Cookbook – das Herzstück
Getrennt von den einzelnen Projekten liegt eine eigene Collection: das Cookbook. Projektübergreifend, generisch, und genau das macht es so wertvoll. Hier steht, wie ich baue, unabhängig davon, an welchem Produkt ich gerade sitze.
Grob gegliedert ist es in ein paar Bereiche:
- Conventions – Naming, Code Style, DocBlocks, Git-Commits, Markdown, Package Manager, Schreibstil. Die langweiligen, aber entscheidenden Dinge, über die man pro Projekt sonst dreimal neu diskutiert.
- Backend – Layer-Architektur, einheitliches API-Error-Format, Test-Strategie, Migrations und Indexes, i18n, asynchrone Jobs und Idempotenz.
- Frontend / Mobile – Architektur nach Feature-First (
core/,shared/,features/), Design System, Forms, Networking, State, Routing, Storage, Styling, Testing. - Deployment – mein Standard-Setup mit Caddy als Edge und Hetzner-VPS.
- Templates – ein ADR-Template und ein
RULES.mdals Projekt-Startpunkt.
Zwei Einträge mag ich besonders. Der eine heißt sinngemäß "Bewusste Nicht-Entscheidungen": dokumentierte Dinge, die ich absichtlich nicht tue oder nicht einsetze, inklusive Begründung. Das ist oft wertvoller als die Positiv-Liste – es verhindert, dass ein Assistent (oder ich selbst in sechs Monaten) eine längst verworfene Idee wieder ausgräbt.
Der andere ist ein "AI Workflow"-Bereich mit einem Pattern, das ich "Spec-as-Outline" nenne: die Spec lebt im Wiki, nicht als loses Prompt-Fragment.
Wie ein Eintrag aussieht
Die Einträge sind kurz, meinungsstark und mit Begründung. Kein Lehrbuch, sondern Entscheidungen. Ein Beispiel, das unkritisch genug ist, um es hier zu zeigen – die Regel zur Non-Null-Assertion in TypeScript:
Oben steht die Essenz als eine Regel. Darunter eine kleine Entscheidungstabelle: Wann nehme ich Optional Chaining (?.), wann eine Assertion (!.), wann lieber einen expliziten Guard-Helper. Und dann zwei, drei Beispiele, sauber getrennt in "legitim" und "smell".
// legitim: Wert ist durch vorherige Logik garantiert vorhanden
const user = users.find(u => u.id === id)!
// smell: Assertion verdeckt einen ungeprüften Nullable
const name = response.data!.user!.name
So sieht das Niveau aus, auf dem das Cookbook arbeitet: granular genug, dass eine konkrete Entscheidung herauskommt, knapp genug, dass man es in zehn Sekunden liest.
Pro Projekt eine eigene Collection
Neben dem Cookbook bekommt jedes Projekt seine eigene Collection. Aktuell ist mindestens eines voll gepflegt. Die Gliederung ist bewusst immer gleich:
"Über das Produkt", "Konzepte & Grundlagen" für das Domänen-Wissen, "Architektur & Tech" für Authorization, API und Tech-Stack, projekt-spezifische "Conventions", ein nach Sub-Domänen gegliedertes "Datenmodell", "Prozesse & Workflows" sowie "Roadmap & Entscheidungen" – Letzteres inklusive ADRs für die bewussten Architektur-Entscheidungen.
Wichtig ist mir hier nur die Gliederungs-Ebene: ein klar strukturierter Ort, an dem das Wissen über ein Produkt vollständig liegt. Was inhaltlich drinsteht, bleibt zwischen mir, dem Team und dem Produkt.
Wie Claude darauf zugreift – und warum es Tokens spart
Der Zugriff läuft über den offiziellen Outline-MCP-Server. Eingerichtet, eingebunden, läuft. Was mich positiv überrascht hat: Der Token-Verbrauch steigt dadurch nicht spürbar. Claude fetcht nicht ständig das halbe Wiki, sondern gezielt.
Dabei hilft ein Pattern, das ich mir in einem Projekt selbst gebaut habe und hier nur als Konzept beschreibe – nicht als Vorlage zum Nachmachen. Ein kleines, config-gesteuertes docs-sync-Tool zieht aus dem Outline-Wiki einen lokalen Snapshot ins Repo: ein paar Markdown-Dateien wie cookbook.md, conventions.md oder models.md unter spec/. Damit liegen die wichtigsten Infos lokal vor und müssen nicht bei jeder Frage frisch über MCP geholt werden.
Erst wenn ich wirklich Details zu einem bestimmten Eintrag brauche, wird gezielt ein Dokument über MCP nachgeladen. Der lokale Snapshot ist die Schnellzugriffs-Schicht, MCP die Tiefe bei Bedarf. Nebenbei kann das Tool aus den Datenmodell-Docs ein Mermaid-ER-Diagramm generieren und per ZIP-Export ein Backup ziehen.
Das ist die pragmatische Variante. Den naheliegenden Schritt – irgendwann RAG über einen eigenen MCP nachzurüsten – habe ich im Hinterkopf, aber bewusst nicht gebaut. Aktuell brauche ich ihn nicht, und das einfachste System, das funktioniert, gewinnt.
Der Moment, in dem es magisch wurde
Den eigentlichen Payoff habe ich bei den ersten Screen-Designs für eines meiner Produkte erlebt.
Ich habe Design-Entwürfe generieren lassen, mit einem Prompt, der – das weiß ich genau – bestimmte Ideen nicht enthielt. Trotzdem tauchten sie im Ergebnis auf. Detaillierte Überlegungen, die ich irgendwann mal im Wiki festgehalten und längst aus dem aktiven Gedächtnis verloren hatte, fanden ihren Weg in die Designs. Nicht weil ich sie geprompted hatte, sondern weil der MCP-Kontext sie mitgebracht hat.
Mein erster Gedanke war ehrlich nur: magisch.
Und genau das ist der Punkt des ganzen Setups. Es geht nicht darum, dass der Assistent meine Notizen abtippt. Es geht darum, dass er Wissen einbringt, das ich im Prompt vergessen oder weggelassen habe. Das Wiki wird zum zweiten Gedächtnis, auf das die AI direkt zugreift – und das gleicht genau die menschliche Schwäche aus, in einem konkreten Moment nicht an alles zu denken.
Das ist kein fertiges System, und es ist nicht für jeden. Es lohnt sich erst, wenn man über mehrere Projekte hinweg dieselben Entscheidungen trifft und es leid ist, sie ständig neu zu erklären. Ab diesem Punkt aber zahlt jeder Eintrag, den man einmal sauber aufschreibt, immer wieder ein – an Konsistenz, an Tempo, und an der seltsam beruhigenden Gewissheit, dass die AI mehr über mein Produkt weiß, als in den aktuellen Prompt passt.
Das Cookbook schreibe ich für mich. Dass Claude mitliest, ist der eigentliche Trick.