Context Engineering: Ein Knowledge OS mit Claude aufbauen

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

• Anthropic – Claude Code Documentation
• Simon Willison – Context Engineering
• Tobi Lutke – Context Engineering (X/Twitter, 2025)
• Wikipedia – Context Engineering

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.