Was passiert, wenn man aufhört zu prompten und anfängt, Kontext zu architektieren. Ein Praxisbericht über den Aufbau eines git-versionierten Knowledge OS — und was ich dabei über die Arbeit mit LLMs gelernt habe.
Der Unterschied: Prompting heißt Anweisungen schreiben. Context Engineering heißt, die Umgebung zu gestalten, in der ein LLM denkt. Das ist nicht dasselbe — ein guter Prompt liefert eine gute Antwort; ein gutes Kontextsystem liefert konsistent gute Antworten über Sessions, Aufgaben und Domänen hinweg. Mein Setup: ein git-versioniertes Markdown-Repository (Obsidian Vault) mit einem 3-Layer-Kontextprinzip, das jede LLM-Interaktion speist.
Layer 1 (Global): CLAUDE.md + Systemdateien — wer ich bin, wie ich arbeite, welche Konventionen gelten. Immer präsent. Layer 2 (Projekt): Jeder Track hat eigene README und Status — Kontext wird auf die aktive Domäne eingegrenzt. Layer 3 (Task): Einzelne Dateien, Skills, Commands — das spezifische Material für die jeweilige Aufgabe.
Warum das funktioniert: Das LLM bekommt progressiv engeren Kontext, ohne das Gesamtbild zu verlieren. Kein redundantes Wiedererklären. Kein Kontextdrift über Sessions hinweg.
Keine statische Konfigurationsdatei — ein sich ständig weiterentwickelndes Dokument, das Arbeitsstil, Konventionen, Projektlandschaft und Entscheidungsrahmen codiert. Die wirkungsvollste einzelne Datei im System. Jede Änderung an Rollen, Tools oder Projekten propagiert durch eine Abhängigkeitsmatrix, um das gesamte System konsistent zu halten.
Das Knowledge OS ist tool-agnostisch: reines Markdown, git-versioniert, keine proprietären Formate. Claude Code ist heute das primäre Interface, aber die Architektur hängt nicht davon ab. Skills und Commands sind die einzige Claude-spezifische Schicht — ihre Logik ist dokumentiert und übertragbar. Das ist eine bewusste Designentscheidung: Das Wissen soll jedes einzelne Tool überdauern.
Konkrete Ergebnisse in sechs Bereichen:
01 Kontext als Produkt: Wenn Context Engineering das neue UX für AI ist — wie sähe ein „Context Design System” aus? Wiederverwendbare Patterns, geteilte Konventionen, komponierbare Layer?
02 Design Leadership: Wie helfen wir nicht-technischen Teammitgliedern, effektive Kontextsysteme aufzubauen? Gibt es einen niedrigschwelligen Einstieg, oder braucht es technische Kompetenz?
03 Knowledge Debt: Jedes Wissenssystem akkumuliert Schulden. Was ist eine nachhaltige Wartungspraxis — und ab wann übersteigen die Wartungskosten den Wert des Systems?
04 Beyond Solo: Das hier ist ein persönliches Knowledge OS. Was ändert sich, wenn man Context Engineering auf ein Team von 5, 15, 50 Personen skaliert? Was bleibt, was bricht?
Context Engineering Gestaltung der persistenten Informationsumgebung, in der ein LLM arbeitet — jenseits einzelner Prompts. Umfasst System-Prompts, Dateistrukturen, Konventionen und Abhängigkeitssysteme.
Knowledge OS Ein strukturiertes, git-versioniertes Wissens-Repository, das sowohl menschliches Denken als auch LLM-Kontext bedient. Reines Markdown, tool-agnostisch, mit geschichteter Kontextarchitektur.
3-Layer Context Architektur-Pattern: Globaler Kontext (Identität, Konventionen) → Projektkontext (Domäne, Status) → Task-Kontext (spezifische Dateien, Commands). Verengt den Scope progressiv, ohne die Kohärenz zu verlieren.
CLAUDE.md Eine Instruktionsdatei auf Projektebene, die Claude Code beim Session-Start liest. Funktioniert als „System Prompt” für ein Repository — codiert Identität, Konventionen und Navigation.
Weiterführende Betrachtung auf Panoptia Labs