Context Engineering: Ein Knowledge OS mit Claude aufbauen

8. März 2026 · David Latz

TL;DR

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.

Reasoning Seed

Spannung: Wenn der Kontext die Qualität der Antwort bestimmt — wird Wissensarchitektur zur eigentlichen Kernkompetenz?

Einordnung: Praxisbericht aus dem Lab: Wie wir mit strukturiertem Kontext bessere AI-Ergebnisse erzielen — und warum das Knowledge OS unser zentrales Werkzeug für Wissensarbeit geworden ist.

Wesentliche Insights

1 — Von Prompting zu Context Architecture

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.

2 — Das 3-Layer-Kontextprinzip

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.

3 — CLAUDE.md als lebendes Dokument

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.

4 — LLM-agnostisch by Design

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.

5 — Was sich in meiner Praxis tatsächlich verändert hat

Konkrete Ergebnisse in sechs Bereichen:

Reflexion: Strukturierte Dialoge, die mein eigenes Denken herausfordern — keine Bestätigung, sondern produktive Reibung
Recherche: Marktanalyse, Entscheidungsrahmen, Problemraum-Exploration — schneller und systematischer
Produktion: Konzepte, E-Mails, Workshop-Vorbereitung, Prototypen — von Stunden auf Minuten für erste Entwürfe
Schreiben: Ein Dialog, der zum Schreiben anregt und Geschriebenes rigoros redigiert
Entwicklung: Funktionale Prototypen (HTML/CSS/JS/React/Tailwind) als Nicht-Entwickler
Organisation: Knowledge-Base-Pflege, Aufgabenstrukturierung, Lernpfade

6 — Lessons Learned: Was nicht funktioniert

Kontext-Overload: Mehr Kontext ist nicht immer besser — es gibt einen Sweet Spot zwischen Vollständigkeit und Rauschen
Wartungsschulden: Ein lebendiges System braucht Pflege. Veralteter Kontext führt aktiv in die Irre
Das Automatisierungsparadox: Ein System aufbauen, das Zeit spart, kostet erstmal erheblich Zeit
Permission-Friction: Tool-Konfigurationen, die den Flow blockieren, sind echte Produktivitätskiller
Transfer-Grenzen: Was für ein Gehirn funktioniert, funktioniert nicht automatisch für ein anderes

Einordnung

Das hier ist ein Erfahrungsbericht aus erster Hand — geschrieben von demjenigen, der das beschriebene System gebaut hat und täglich nutzt. Diese Nähe ermöglicht konkrete Aussagen über Praxistauglichkeit und Grenzen, erzeugt aber auch einen blinden Fleck: Die Bewertung des eigenen Systems ist unvermeidlich durch die investierte Zeit und die persönliche Passung gefärbt. Ein Informationswissenschaftler würde die Knowledge-Management-Aspekte systematischer einordnen; ein Software-Architekt würde die Skalierbarkeit kritischer prüfen.

Kritische Einordnung

Warum Designer sich dafür interessieren sollten

Context Engineering ist Informationsarchitektur für AI — eine Design-Disziplin, kein Engineering-Problem
Design Leaders, die Kontextsysteme verstehen, können gestalten, wie Teams mit AI interagieren — nicht nur, dass sie es tun
Die Skills übertragen sich direkt: User Research, Systems Thinking, Service Design

Was noch fehlt

Team-Scale-Patterns: Das hier ist ein Solo-Setup — kollaborative Kontextsysteme sind ungelöst
Evaluierungs-Frameworks: Wie misst man, ob die eigene Kontextarchitektur tatsächlich funktioniert?
Onboarding: Die Lernkurve ist real — das ist kein Wochenendprojekt
Standardisierung: Jeder Practitioner baut sein eigenes System von Grund auf

Diskussionsfragen

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?

Quellen

Glossar

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.

Kuratiert von David Latz · Panoptia März 2026