Claude Code Masterkurs – KI-gestuetztes Programmieren lernen mit Anthropics Coding-Agent

Context Engineering Masterclass

Level 3 | 50 Minuten

Die Kunst des Context Engineering — Von Context Rot über die 4 Säulen bis zu praktischen Übungen und messbaren Lern-Outcomes

Lernziele

Context Engineering — Die neue Schlüsseldisziplin

Context Engineering ist die wichtigste Fähigkeit die du als Claude Code Nutzer entwickeln kannst — wichtiger als Prompting, wichtiger als Tool-Kenntnis, wichtiger als technisches Wissen. Anthropic selbst sagt: 'Die Intelligenz deines Agents ist direkt proportional zur Qualität des Kontexts den du bereitstellst.' Was ist Context Engineering? Es ist die Kunst und Wissenschaft, die GESAMTE Informationsumgebung zu gestalten in der Claude arbeitet. Nicht nur was du in einem einzelnen Prompt schreibst, sondern: Welche Dateien Claude sieht, welche Regeln in der CLAUDE.md stehen, welche Skills geladen werden, wie der Konversationsverlauf gemanagt wird, und wann Informationen komprimiert oder isoliert werden. Der Unterschied zu Prompt Engineering: Prompt Engineering optimiert eine EINZELNE Nachricht. Context Engineering optimiert das GESAMTE System. Ein perfekter Prompt in einem schlecht gemanagten Kontext liefert schlechtere Ergebnisse als ein durchschnittlicher Prompt in einem perfekt gestalteten Kontext. Warum ist das so wichtig? Weil das Context Window die fundamentale Beschränkung jedes KI-Agents ist. Selbst mit 1M Tokens (Opus/Sonnet 4.6) bist du in einem Enterprise-Projekt mit CLAUDE.md, MCP-Servern, Skills und 50+ Nachrichten Konversation schnell bei 60-80% — und die Qualität sinkt ab 90%. Context Engineering löst dieses Problem durch vier Strategien (die wir in dieser Lektion im Detail behandeln): WRITE (permanenten Kontext bereitstellen), SELECT (gezielt relevante Informationen laden), COMPRESS (Kontext komprimieren ohne wichtige Details zu verlieren), und ISOLATE (Aufgaben in separate Kontexte aufteilen). Diese vier Säulen bilden zusammen ein Framework das dich vom gelegentlichen Claude Code Nutzer zum effektiven Power User macht. Jede Säule hat eigene Techniken und Tools — zusammen ergeben sie ein System das die Qualität deiner Ergebnisse fundamental verbessert.

💡 Anthropics Definition Context Engineering = Die Optimierung des Token-Nutzens unter den inhärenten Beschränkungen von LLMs, um konsistent ein gewünschtes Ergebnis zu erzielen. Es geht darum, den ganzheitlichen Zustand zu berücksichtigen, der dem LLM zu jedem Zeitpunkt zur Verfügung steht — nicht nur den einen Prompt.

Context Engineering vs. Prompt Engineering

Viele Entwickler konzentrieren sich auf den perfekten Prompt — aber das ist nur die Spitze des Eisbergs. Context Engineering geht weit darüber hinaus und gestaltet die GESAMTE Informationslandschaft in der Claude arbeitet. Prompt Engineering fragt: 'Wie formuliere ich meine Anfrage optimal?' Context Engineering fragt: 'Wie stelle ich sicher, dass Claude ALLES hat was es braucht — BEVOR ich überhaupt meine Anfrage formuliere?' Ein Beispiel macht den Unterschied klar. Prompt Engineering: 'Implementiere eine Authentifizierung mit JWT, nutze bcrypt für Hashing, erstelle Middleware für Route-Protection, und schreib Tests mit Jest.' Context Engineering: Eine CLAUDE.md die den gesamten Auth-Stack dokumentiert, ein Security-Skill der Best Practices enthält, eine .claudeignore die irrelevante Dateien ausschließt, und eine Session die mit /compact frisch gehalten wird. Der Prompt: 'Implementiere die Authentifizierung.' Im zweiten Fall braucht der Prompt nur 4 Wörter, weil der KONTEXT alles andere enthält. Claude kennt die Architektur, die Libraries, die Konventionen und die Security-Anforderungen — aus der CLAUDE.md und den Skills. Der Code wird konsistenter und vollständiger weil die Informationen dauerhaft verfügbar sind, nicht nur in einem einzelnen Prompt. Das Kosten-Argument: Guter Kontext spart Token. Wenn jeder Prompt 200 Wörter Wiederholung enthält ('Nutze TypeScript, React 18, Zustand für State...'), verbrauchst du bei 50 Prompts pro Tag 10.000 Tokens NUR für Wiederholungen. Mit CLAUDE.md: 0 Token Wiederholung. Die Investition: 1-2 Stunden für eine gute CLAUDE.md, .claudeignore und 2-3 Skills. Der Return: Jede Session besser, jeder Prompt kürzer, jedes Ergebnis konsistenter. Über Wochen und Monate ist das ein enormer Hebel.

PROMPT ENGINEERING (alt)              CONTEXT ENGINEERING (neu)
━━━━━━━━━━━━━━━━━━━━━━━━              ━━━━━━━━━━━━━━━━━━━━━━━━━
"Finde die richtigen Worte"          "Konfiguriere den richtigen Zustand"
Fokus: Eine einzelne Anfrage          Fokus: Gesamter Token-Pool
Optimiert: Formulierung                Optimiert: Alle verfügbaren Tokens
Scope: Ein Prompt                      Scope: System + CLAUDE.md + Files
                                              + Konversation + Tools + Memory

ANALOGIE:
━━━━━━━━━
Prompt Engineering = Dem Koch sagen was er kochen soll
Context Engineering = Die gesamte Küche einrichten:
  → Zutaten vorbereiten (CLAUDE.md, relevante Files)
  → Rezept bereitstellen (Skills, Workflows)
  → Werkzeuge bereitlegen (MCP Server, Tools)
  → Küche organisieren (.claudeignore, --include)
  → Aufräumen wenn nötig (/compact, /clear)

Context Rot — Das größte Problem verstehen

Context Rot ist ein wissenschaftlich dokumentiertes Phänomen das die Performance von KI-Agents systematisch verschlechtert. Es entsteht wenn das Context Window sich füllt und Claude mit zu vielen Informationen gleichzeitig arbeiten muss. Das Ergebnis: Schleichender Qualitätsverlust der oft erst bemerkt wird wenn er bereits erheblichen Schaden angerichtet hat. Die Analogie: Stell dir einen Schreibtisch vor. Am Anfang ist er leer und du kannst effizient arbeiten. Mit jeder Aufgabe legst du neue Dokumente ab. Nach ein paar Stunden ist der Schreibtisch so voll, dass du 30 Sekunden suchst bevor du das richtige Dokument findest. Irgendwann ist er so überfüllt, dass du Dokumente verwechselst und Fehler machst. Claude's Context Window IST dieser Schreibtisch. Das Tückische an Context Rot: Es ist nicht binär. Es gibt keinen Moment wo Claude plötzlich 'aufhört zu funktionieren'. Stattdessen verschlechtert sich die Qualität graduell. Bei 50% Auslastung ist alles noch gut. Bei 60% übersieht Claude vielleicht ein Detail. Bei 70% widerspricht es sich gelegentlich. Bei 80% werden die Fehler systematisch. Bei 90% ist der Output oft wertlos. Die wissenschaftliche Erklärung: Transformer-basierte Sprachmodelle verarbeiten ALLE Tokens im Kontext bei jeder Anfrage. Je mehr Tokens, desto mehr 'Rauschen' muss das Modell filtern um die relevante Information zu finden. Ab einem bestimmten Punkt überwiegt das Rauschen und die Qualität leidet. Die häufigsten Symptome: Claude wiederholt sich. Claude widerspricht früheren Aussagen. Claude ignoriert Konventionen die es anfangs eingehalten hat. Code-Stil wird inkonsistent. Fehlerbehandlung wird vergessen. Tests sind oberflächlich. Die gute Nachricht: Context Rot ist vollständig vermeidbar — wenn du die vier Säulen des Context Engineering anwendest.

DIE 5 PHASEN DER CONTEXT ROT
━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 1: FRISCH 🟢 (0-25% Context)
→ Perfekte Ergebnisse, schnelle Antworten
→ Claude versteht alles, kein Vergessen

Phase 2: PRODUKTIV 🟡 (25-50% Context)
→ Gute Ergebnisse, leicht langsamer
→ Gelegentlich redundante Datei-Reads

Phase 3: DEGRADIERT 🟠 (50-75% Context)
→ Antworten werden unpräziser
→ Claude wiederholt sich, "compacting" beginnt
→ HANDLUNGSBEDARF: /compact jetzt nutzen!

Phase 4: KRITISCH 🔴 (75-90% Context)
→ Claude vergisst kürzliche Entscheidungen
→ Bugs werden wieder eingeführt
→ Architektur-Entscheidungen ignoriert
→ SOFORT /clear oder neue Session!

Phase 5: KOLLAPS 💀 (>90% Context)
→ Auto-Compaction entfernt wichtige Details
→ Claude halluziniert Dateien/Funktionen
→ Antworten sind inkohärent
→ NEUE SESSION ist die einzige Lösung

Context Rot erkennen — Die Warnsignale

Die Warnsignale von Context Rot zu erkennen ist eine der wichtigsten Fähigkeiten im Umgang mit Claude Code. Je früher du eingreifst, desto weniger Schaden entsteht. Hier sind die konkreten Anzeichen die du beobachten solltest. Warnsignal 1 — Widersprüchliche Entscheidungen: Claude hat vor 10 Nachrichten entschieden, async/await statt Callbacks zu nutzen. Jetzt generiert es plötzlich Code mit Callbacks. Das ist ein klares Zeichen dass der frühere Kontext nicht mehr richtig berücksichtigt wird. Warnsignal 2 — Vergessene Konventionen: Am Anfang der Session hielt Claude sich an eure Naming-Convention (camelCase). Jetzt mixt es plötzlich snake_case ein. Oder: Es nutzt plötzlich eine andere Library als die vereinbarte. Warnsignal 3 — Wiederholte Erklärungen: Claude erklärt dir etwas das es vor 5 Nachrichten schon erklärt hat — als ob es die vorherige Erklärung vergessen hätte. Das zeigt, dass ältere Konversationsteile an Gewicht verlieren. Warnsignal 4 — Qualitätsabfall: Die ersten Funktionen hatten umfassende Error-Handling, saubere Typisierung und Dokumentation. Die neuesten Funktionen sind deutlich schlichter — weniger Validierung, keine Kommentare, vereinfachte Typen. Warnsignal 5 — Wachsende Response-Zeiten: Claude braucht länger für jede Antwort weil es mehr Kontext verarbeiten muss. Das ist ein indirektes Signal für hohe Context-Auslastung. Sofort-Maßnahmen wenn du Warnsignale erkennst: /context prüfen. Bei über 60%: /compact ausführen. Bei über 80%: Neue Session starten. Die aktuelle Arbeit sichern (committen) und mit frischem Kontext fortfahren. Präventiv: Alle 15-20 Nachrichten oder alle 20 Minuten routinemäßig /compact ausführen — auch wenn noch keine Warnsignale sichtbar sind. Vorbeugung ist effektiver als Heilung.

Die 4 Säulen des Context Engineering

Anthropic definiert vier zentrale Strategien für effektives Context Engineering — die vier Säulen. Zusammen bilden sie ein vollständiges Framework das alle Aspekte des Context Managements abdeckt. Jede Säule hat eigene Tools, Techniken und Anwendungsfälle. Säule 1 — WRITE: Permanenten Kontext bereitstellen. Die CLAUDE.md, Skills, System-Prompts und Agent-Konfigurationen. Alles was bei JEDER Session automatisch verfügbar sein soll, ohne dass du es wiederholen musst. WRITE ist das Fundament — einmal investieren, dauerhaft profitieren. Säule 2 — SELECT: Gezielt relevante Informationen laden. --include/--exclude Flags, .claudeignore, und bewusste Dateiauswahl. Nicht alles was existiert ist relevant für die aktuelle Aufgabe. SELECT hilft dir, den Kontext auf das Wesentliche zu fokussieren. Säule 3 — COMPRESS: Bestehenden Kontext komprimieren. /compact, gezielte Zusammenfassungen und Kontext-Reduktion. Wenn der Kontext wächst, musst du ihn regelmäßig verdichten — die wichtigen Informationen behalten, den Ballast entfernen. Säule 4 — ISOLATE: Aufgaben in separate Kontexte aufteilen. Subagents, neue Sessions und das SCRATCHPAD-Pattern. Statt alles in einem überfüllten Kontext zu bearbeiten, verteilst du die Arbeit auf mehrere isolierte Kontexte. Die vier Säulen sind nicht unabhängig — sie arbeiten zusammen. WRITE stellt das Fundament bereit. SELECT fokussiert auf das Relevante. COMPRESS hält den Kontext frisch. ISOLATE verhindert Überlastung. Gemeinsam halten sie Claude in der optimalen Arbeitszone. In den folgenden Abschnitten gehen wir jede Säule im Detail durch: Was genau tut sie? Welche Tools und Techniken gibt es? Wie setzt du sie in der Praxis ein? Wann ist welche Säule am wichtigsten?

DIE 4 SÄULEN
━━━━━━━━━━━━

┌─────────────────────────────────────────────────┐
│  1. WRITE    │  Kontext schreiben & bereitstellen  │
│  ──────────  │  CLAUDE.md, Skills, System Prompts  │
│              │  → Wissen einmal definieren,         │
│              │  → automatisch in jede Session laden │
├──────────────┼─────────────────────────────────────┤
│  2. SELECT   │  Relevanten Kontext auswählen        │
│  ──────────  │  --include, --exclude, .claudeignore │
│              │  → Nur relevante Dateien laden       │
│              │  → Token-Budget nicht verschwenden    │
├──────────────┼─────────────────────────────────────┤
│  3. COMPRESS │  Kontext komprimieren                │
│  ──────────  │  /compact, Auto-Compaction           │
│              │  → Konversation zusammenfassen        │
│              │  → Platz für neue Tokens schaffen     │
├──────────────┼─────────────────────────────────────┤
│  4. ISOLATE  │  Kontext isolieren                   │
│  ──────────  │  Subagents, neue Sessions            │
│              │  → Unabhängige Tasks separieren       │
│              │  → Context Rot in Subbereichen        │
│              │    verhindert nicht den Hauptbereich  │
└──────────────┴─────────────────────────────────────┘

Säule 1: WRITE — Kontext intelligent bereitstellen

Die erste Säule WRITE befasst sich mit permanentem Kontext — Informationen die bei JEDER Claude Code Session automatisch verfügbar sind. Statt jedes Mal aufs Neue zu erklären wie dein Projekt aufgebaut ist, schreibst du es einmal auf und es wird immer geladen. Das Hauptinstrument von WRITE ist die CLAUDE.md. Sie wird bei jedem Session-Start automatisch gelesen und bildet das Fundament von Claudes Projektverständnis. Alles was Claude IMMER wissen muss, gehört hierhin: Tech-Stack, Konventionen, Architektur-Entscheidungen, Business-Logik, Security-Anforderungen. Skills sind das zweite WRITE-Instrument. Während die CLAUDE.md immer geladen wird, werden Skills nur geladen wenn sie für den aktuellen Task relevant sind. Das ermöglicht tiefes Fachwissen ohne permanenten Kontext-Verbrauch. Ein Testing-Skill wird nur geladen wenn du Tests schreibst, ein Security-Skill nur beim Security-Review. Die Kombination aus CLAUDE.md und Skills ist mächtig: Die CLAUDE.md enthält die universellen 20% des Wissens die für 80% der Aufgaben relevant sind. Skills enthalten die spezialisierten 80% des Wissens die jeweils nur für 20% der Aufgaben relevant sind. Die Kunst des guten WRITE: Nicht zu viel und nicht zu wenig. Jedes Wort in der CLAUDE.md verbraucht Token — bei JEDER Nachricht. Eine 5000-Wörter CLAUDE.md kostet pro Nachricht ~7.000 Tokens. Bei 30 Nachrichten sind das 210.000 Tokens nur für die CLAUDE.md — mehr als das gesamte Context Window! Halte die CLAUDE.md unter 2000 Wörtern und lagere Details in Skills aus. Das Memory-System ergänzt WRITE: Mit /memory kannst du während einer Session Erkenntnisse dauerhaft in die CLAUDE.md schreiben. So wächst dein permanenter Kontext organisch mit deinem Projekt.

# CLAUDE.md — Dein permanentes Gedächtnis
# Diese Datei wird bei JEDER Session automatisch geladen

## Projekt-Architektur
- Monorepo mit Turborepo
- Frontend: Next.js 15 App Router
- Backend: Express + Prisma + PostgreSQL
- Alle API Routes in /src/app/api/

## Aktuelle Sprint-Entscheidungen
- Auth: JWT + HttpOnly Cookies (NICHT Session-basiert!)
- State: Zustand (NICHT Redux)
- Styling: Tailwind + shadcn/ui
- Testing: Vitest + Playwright

## Code-Konventionen
- Keine default exports
- Alle Funktionen typisiert (kein any)
- Error Handling: Result-Pattern statt try/catch
- Dateinamen: kebab-case

## WICHTIG: Nicht ändern
- /src/legacy/ ist read-only (Migration läuft separat)
- DB-Schema nur über Prisma Migrations ändern

Säule 2: SELECT — Gezielt laden statt alles lesen

Die zweite Säule SELECT bestimmt welche Informationen Claude für die aktuelle Aufgabe sieht. Statt den gesamten Projektkontext zu laden, wählst du gezielt aus was relevant ist. Das hält den Kontext fokussiert und gibt Claude mehr Platz für die eigentliche Arbeit. Das einfachste SELECT-Tool: --include beim Start. 'claude --include src/auth/ src/middleware/' startet Claude mit nur diesen Verzeichnissen im Kontext. Alles andere wird ignoriert. Perfekt wenn du genau weißt in welchem Bereich du arbeitest. Das Gegenstück: --exclude schließt bestimmte Bereiche aus. 'claude --exclude tests/ docs/' wenn du nur am Produktionscode arbeitest und Tests und Dokumentation gerade nicht brauchst. Die .claudeignore ist permanentes SELECT: Dateien die NIEMALS geladen werden sollen, egal in welcher Session. node_modules, dist, build, .git — alles was nur Kontext verschwendet. Innerhalb einer Session kannst du SELECT durch gezielte Dateireferenzen steuern: Statt 'Analysiere den Code' (Claude liest möglicherweise alles), sag 'Analysiere @src/auth/login.ts und @src/auth/session.ts'. Damit bekommt Claude genau die Dateien die es braucht. SELECT hat auch eine zeitliche Dimension: Nicht alle Informationen sind während der gesamten Session relevant. Die Analyse-Ergebnisse vom Anfang braucht Claude bei der Implementierung am Ende möglicherweise nicht mehr. /compact nach der Analyse-Phase behält die Zusammenfassung und entfernt die Details. Die goldene Regel: Lade nur was Claude JETZT braucht, nicht was es VIELLEICHT braucht. Bei Bedarf kannst du jederzeit weitere Dateien laden. Zu viel Kontext ist genauso schädlich wie zu wenig.

# ANTI-PATTERN: Alles laden
claude "Analysiere das gesamte Projekt"
# → Hunderttausende Tokens sofort verbraucht, Context Rot vorprogrammiert

# BEST PRACTICE: Gezielt laden
claude --include "src/auth/**/*" "Implementiere Password Reset"
# → Nur Auth-Dateien geladen, präziser Kontext

# Noch besser: Kombinierte Selektion
claude \
  --include "src/auth/**/*.ts" \
  --include "src/types/auth.ts" \
  --include "prisma/schema.prisma" \
  --exclude "**/*.test.ts" \
  --exclude "**/*.spec.ts" \
  "Implementiere Password Reset mit Token-Ablauf"

# Ordner-spezifische CLAUDE.md für automatische Selektion
# src/auth/CLAUDE.md → wird NUR geladen wenn in src/auth/ gearbeitet wird
# src/api/CLAUDE.md → wird NUR geladen wenn in src/api/ gearbeitet wird

# .claudeignore für permanenten Ausschluss
# Reduziert den "Grundrauschen"-Kontext um 40-60%

Säule 3: COMPRESS — Kontext komprimieren

Die dritte Säule COMPRESS befasst sich mit der Verdichtung von bestehendem Kontext. Lange Konversationen sammeln redundante, veraltete und irrelevante Informationen. COMPRESS hilft dir, den Kontext zu komprimieren ohne die wichtigen Details zu verlieren. Das Hauptwerkzeug: /compact. Dieser Befehl fasst die gesamte bisherige Konversation in eine kompakte Zusammenfassung zusammen. Aus 50.000 Tokens Konversation werden vielleicht 5.000 Tokens Essenz. Die Kernentscheidungen, Patterns und offenen Aufgaben bleiben erhalten. /compact ist besonders effektiv weil es INTELLIGENT komprimiert: Claude erkennt was wichtig ist (Architektur-Entscheidungen, Code-Patterns, offene Todos) und was Ballast ist (explorative Fragen, verworfene Ansätze, Wiederholungen). Das Ergebnis ist ein destillierter Kontext der die gleichen Informationen in einem Bruchteil des Platzes enthält. Wann komprimieren? Regelmäßig und proaktiv — nicht erst wenn Probleme auftreten. Empfohlene Intervalle: Nach 15-20 Nachrichten (zeitbasiert), bei über 50% Context-Auslastung (platzbasiert), nach Abschluss einer Teilaufgabe (aufgabenbasiert), oder wenn du Warnsignale von Context Rot erkennst. Fortgeschrittene COMPRESS-Technik: Du kannst Claude bitten, eine SPEZIFISCHE Zusammenfassung zu erstellen statt /compact zu nutzen. 'Fasse die bisherigen Architektur-Entscheidungen in 5 Bullet Points zusammen' gibt dir eine kontrolliertere Komprimierung. COMPRESS hat einen Trade-off: Details gehen verloren. Wenn du nach /compact eine Frage stellst die sich auf ein spezifisches Detail von vor 15 Nachrichten bezieht, hat Claude es möglicherweise nicht in der Zusammenfassung behalten. Die Lösung: Wichtige Details vor dem Compact explizit in der CLAUDE.md festhalten (/memory).

# Standard-Komprimierung
/compact
# → Claude fasst die bisherige Konversation zusammen
# → Behält Kernentscheidungen, entfernt Redundanz

# Gezielte Komprimierung (PRO-TIPP)
/compact keep only: current file changes, error messages, architectural decisions
# → Du bestimmst WAS behalten wird!

# Wann /compact nutzen?
# ┌─────────────────────────────────────────┐
# │ REGEL: Alle 10-15 Nachrichten           │
# │ ODER wenn /cost > 40% Context zeigt     │
# │ ODER bei erstem "compacting..." Hinweis │
# └─────────────────────────────────────────┘

# AUTO-COMPACTION verstehen:
# Claude komprimiert AUTOMATISCH wenn der Context voll wird
# ABER: Auto-Compaction ist weniger präzise als manuelle
# → Kann wichtige Details verlieren
# → Besser: MANUELL /compact nutzen BEVOR es nötig wird

Säule 4: ISOLATE — Kontext isolieren

Die vierte Säule ISOLATE ist die mächtigste — sie löst das Context-Problem an der Wurzel: Statt einen einzelnen Kontext immer größer werden zu lassen, verteilst du die Arbeit auf mehrere isolierte Kontexte. Jeder hat seinen eigenen Platz und seine eigene Aufgabe. Das Hauptinstrument: Subagents. Wenn Claude einen Subagent spawnt, arbeitet dieser in seinem eigenen Context Window. Er kann Dateien lesen, Code analysieren, Tests ausführen — alles in seinem eigenen isolierten Raum. Nur das Ergebnis kommt in deinen Hauptkontext zurück. Warum ist das so mächtig? Stell dir vor, du willst 100 Dateien auf Security-Schwachstellen prüfen. In deinem Hauptkontext würde das 100.000+ Tokens verbrauchen und den Kontext ruinieren. Als Subagent: Der Agent liest die 100 Dateien in seinem eigenen Kontext, findet 3 Schwachstellen, und meldet nur zurück: 'Gefunden: SQLi in auth.ts:42, XSS in render.ts:88, CSRF fehlt in api.ts.' Das sind weniger als 50 Tokens in deinem Hauptkontext. Das SCRATCHPAD-Pattern ist eine weitere ISOLATE-Technik: Statt Zwischenergebnisse im Kontext zu halten, schreibt Claude sie in eine temporäre Datei (Scratchpad). Bei Bedarf liest es die Datei, arbeitet damit, und löscht sie wieder. So bleibt der Kontext sauber. Neue Sessions starten ist die einfachste ISOLATE-Methode: Für jede unabhängige Aufgabe eine eigene Session. Die CLAUDE.md sorgt für Konsistenz zwischen den Sessions, und Git sorgt dafür dass die Code-Änderungen zusammenpassen. ISolate ist besonders wertvoll bei: Großen Explorationsaufgaben, parallelen Arbeitssträngen, langen Code-Reviews, und Multi-File-Refactorings. Überall wo viel Kontext anfällt der die Hauptaufgabe nicht direkt betrifft.

# Subagents nutzen für isolierten Kontext
> "Lass einen Subagent die Tests schreiben während wir
>  am Feature weitermachen"
# → Subagent hat eigenen Context, verschmutzt nicht deinen

# SCRATCHPAD-Pattern für Session-übergreifende Arbeit
> "Schreibe den aktuellen Plan in SCRATCHPAD.md"
/clear
> "Lies SCRATCHPAD.md und mache weiter bei Schritt 4"
# → Sauberer Context, Plan bleibt erhalten

# Feature-Branch-Pattern
# Session 1: Feature-Auth planen → Plan in docs/plans/auth.md
/clear
# Session 2: Auth implementieren → Liest Plan, implementiert
/clear
# Session 3: Auth testen → Liest Implementation, schreibt Tests

# Task-Decomposition für große Features
# Statt: "Baue ein komplettes Auth-System"
# Besser: 
#   Session 1: "Erstelle das User-Schema und die DB-Migration"
#   Session 2: "Implementiere Login/Register API Routes"
#   Session 3: "Erstelle die Auth-Middleware"
#   Session 4: "Baue die Frontend-Formulare"

Context Budget planen

Wie ein finanzielles Budget solltest du dein Token-Budget bewusst planen und überwachen. Jede Projekt-Konfiguration und jeder Arbeitsstil verbraucht einen unterschiedlichen Anteil des Context Windows — und dieser Verbrauch bestimmt wie viel Platz für die eigentliche Arbeit bleibt. Der Basis-Verbrauch (bevor du die erste Nachricht tippst): CLAUDE.md ~2.000-5.000 Tokens. System-Prompt ~1.000 Tokens. MCP Server Beschreibungen ~1.000-4.000 pro Server. Bei 5 aktiven MCP Servern: ~5.000-20.000 Tokens. Skills-Index ~500-2.000 Tokens. Gesamt Basis: ~10.000-28.000 Tokens — das sind 5-14% des Context Windows, verbraucht BEI JEDER Nachricht. Der Konversations-Verbrauch: Jede Nachricht (dein Prompt + Claudes Antwort) verbraucht ~500-5.000 Tokens, je nach Komplexität. Bei 20 Nachrichten: ~10.000-100.000 Tokens. Tool-Ergebnisse (gelesene Dateien, Grep-Resultate) verbrauchen zusätzlich ~1.000-10.000 pro Aufruf. Ein Budget-Plan für eine typische Session (Opus/Sonnet 4.6 mit 1M): Basis: 15.000 Tokens (fest). Konversation: 200.000 Tokens (variabel). Tool-Ergebnisse: 300.000 Tokens (variabel). Reserve: 485.000 Tokens (Puffer). Gesamt: 1.000.000 Tokens. Für Haiku (200K): Basis 15K, Konversation 60K, Tools 40K, Reserve 85K. Wenn der Basis-Verbrauch zu hoch ist: MCP Server reduzieren (größter einzelner Hebel), CLAUDE.md kürzen (Details in Skills auslagern), oder Skills-Index optimieren. Wenn der Konversations-Verbrauch zu schnell wächst: Häufiger /compact nutzen, Prompts kürzer halten, oder Aufgaben in separate Sessions aufteilen. Das Budget-Monitoring: /cost zeigt den aktuellen Verbrauch. /context zeigt die Aufteilung. Regelmäßig prüfen und bei Bedarf eingreifen — wie beim Haushaltsgeld.

CONTEXT BUDGET TEMPLATE
━━━━━━━━━━━━━━━━━━━━━━

Verfügbar: 1,000,000 Tokens (100%) — Opus/Sonnet 4.6
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
System Prompt:          ~2,000  (1%)    [Fest]
CLAUDE.md:              ~2,000  (1%)    [Fest, aber optimierbar]
Geladene Dateien:      ~30,000  (15%)   [Steuerbar via --include]
Tool-Outputs (MCP):    ~10,000  (5%)    [Variabel]
Konversation:         ~100,000  (50%)   [Wächst, /compact hilft]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Reserve:               ~56,000  (28%)   [Puffer für Claude's Antworten]

OPTIMIERUNGSHEBEL:
1. CLAUDE.md schlank halten (<2000 Tokens)
   → Skills statt CLAUDE.md für seltene Infos
2. --include statt ganzes Projekt
   → 30K statt 100K für Files
3. /compact alle 10-15 Messages
   → Konversation bleibt bei ~50K
4. Subagents für Tool-heavy Tasks
   → MCP-Overhead in separatem Context

Memory System: Über Sessions hinweg merken

Das Memory System ermöglicht es Claude, wichtige Erkenntnisse ÜBER Sessions hinweg zu behalten. Normalerweise vergisst Claude alles wenn du eine neue Session startest. Mit dem Memory System schreibst du wichtige Informationen dauerhaft in die CLAUDE.md — Claude's Langzeitgedächtnis. Der /memory Befehl ist das Hauptwerkzeug: Während einer Session kannst du Claude bitten, etwas zu merken: '/memory Wir haben entschieden, für die Payment-Integration Stripe Webhooks statt Polling zu nutzen.' Claude fügt diese Information automatisch an die CLAUDE.md an — sie ist damit bei JEDER zukünftigen Session verfügbar. Warum ist das wichtig? Ohne Memory-System passiert Folgendes: In Session 1 entscheidest du dich für eine bestimmte Architektur. In Session 2 hat Claude diese Entscheidung vergessen und schlägt etwas anderes vor. Du erklärst es erneut. In Session 3 passiert das Gleiche. Das ist nicht nur frustrierend, sondern kostet auch Tokens und Zeit. Mit Memory: Die Entscheidung wird einmal gespeichert und ist für immer verfügbar. Keine Wiederholungen, keine Inkonsistenzen, keine vergessenen Entscheidungen. Das Memory System eignet sich besonders für: Architektur-Entscheidungen ('Wir nutzen Repository-Pattern für Datenbankzugriff'), erkannte Bugs und Workarounds ('Die Stripe API hat einen Bug bei Beträgen über 999.999 — nutze Integer Cents'), Team-Konventionen die sich entwickeln ('Tests für neue Komponenten immer mit @testing-library, nicht mit Enzyme'), und Projekt-Fortschritt ('Phase 1 der Migration ist abgeschlossen, Phase 2 beginnt am Montag'). Achtung: Jeder /memory Eintrag vergrößert die CLAUDE.md und damit den Basis-Tokenverbrauch. Räume die Memories regelmäßig auf — lösche veraltete Einträge und konsolidiere redundante.

# Memory-Befehl nutzen
/memory
# → Zeigt was Claude sich über Sessions hinweg gemerkt hat

# Memory hinzufügen
/memory add "Dieses Projekt nutzt pnpm statt npm"
/memory add "Prefer named exports over default exports"
/memory add "Database migrations müssen von DBA reviewed werden"

# Memory vs. CLAUDE.md:
# ┌─────────────────────┬──────────────────────┐
# │ CLAUDE.md           │ /memory              │
# ├─────────────────────┼──────────────────────┤
# │ Projekt-spezifisch  │ Globale Präferenzen  │
# │ Im Repo (Git)       │ Lokal (~/.claude)    │
# │ Team-weit geteilt   │ Nur für dich         │
# │ Manuell editiert    │ Via Command verwaltet │
# └─────────────────────┴──────────────────────┘

# Beispiel: Memory für persönliche Präferenzen
/memory add "Ich bevorzuge funktionale Patterns über Klassen"
/memory add "Kommentare immer auf Deutsch"
/memory add "Tests mit describe/it statt test()"

Anti-Beispiele — Was passiert wenn Kontext fehlt

Theorie allein überzeugt nicht immer. Deshalb hier konkrete Szenarien die zeigen was passiert wenn Context Engineering vernachlässigt wird. Diese Beispiele kommen aus der Praxis — sie sind nicht übertrieben sondern alltäglich. Anti-Beispiel 1 — Fehlende CLAUDE.md: Du bittest Claude 'Erstelle einen User-Service'. Claude generiert einen Service mit Express, nutzt MongoDB, schreibt JavaScript statt TypeScript, und erstellt keine Tests. Dein Projekt nutzt aber NestJS, PostgreSQL, TypeScript und Jest. Ergebnis: Der gesamte Code ist unbrauchbar. Zeitverlust: 20 Minuten für den Prompt plus 30 Minuten für den Neuanfang. Anti-Beispiel 2 — Context Rot: Du arbeitest seit einer Stunde an einem Feature. Am Anfang hielt Claude sich an Conventional Commits. Jetzt — bei 85% Context-Auslastung — committet es mit 'fix stuff' und 'update code'. Die Fehlerbehandlung die anfangs gründlich war, ist jetzt oberflächlich. Du merkst es erst beim Review und musst 5 Commits nacharbeiten. Anti-Beispiel 3 — Kein SELECT: Du startest Claude Code in einem Monorepo mit 2.000 Dateien. Claude scannt alles und das Context Window ist zu 40% voll bevor du die erste Frage stellst. Deine Arbeit betrifft nur 15 Dateien in einem Unterverzeichnis. 38% des Context Windows sind verschwendet. Anti-Beispiel 4 — Fehlende ISOLATE: Du bittest Claude, alle 200 Test-Dateien auf veraltete Patterns zu prüfen. Claude liest alle 200 Dateien in den Hauptkontext. Danach ist das Context Window bei 95% und Claude kann für die eigentliche Implementierung kaum noch denken. Mit einem Subagent: 0 Impact auf den Hauptkontext. Die Lektion: Jedes dieser Probleme ist mit einer einzigen der vier Säulen vollständig vermeidbar. Context Engineering ist kein Luxus — es ist eine Notwendigkeit für produktive Arbeit mit Claude Code.

SZENARIO 1: Fehlende Projekt-Identität
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Du: "Erstelle einen User-Service"
Claude (ohne Kontext): Erstellt Express.js Service mit MongoDB
Realität: Dein Projekt nutzt Next.js API Routes mit PostgreSQL
→ Code ist komplett unbrauchbar

SZENARIO 2: Fehlende Business-Logik
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Du: "Implementiere Rechnungsfreigabe"
Claude (ohne Kontext): Einfacher Approve-Button ohne Limits
Realität: 4-Augen-Prinzip ab 10.000€, Rollen-basierte Limits
→ Sicherheitslücke in Production

SZENARIO 3: Fehlende Security-Requirements
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Du: "Erstelle User-Registrierung"
Claude (ohne Kontext): Basic Form ohne Validation
Realität: DSGVO-Consent, Passwort-Policy, Audit-Log nötig
→ Compliance-Verstoß, potenziell meldepflichtig

SZENARIO 4: Context Rot in langer Session
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stunde 1: Du entscheidest "Wir nutzen Redis für Caching"
Stunde 3: Claude vergisst das und schlägt In-Memory Cache vor
Stunde 4: Du korrigierst, Claude nutzt Redis
Stunde 5: Claude nutzt wieder In-Memory Cache
→ Ständige Korrekturen, frustrierende Zeitverschwendung
🔑 Die Lektion aus den Anti-Beispielen Jedes dieser Probleme ist VERMEIDBAR: Szenario 1 → Projekt-Identität in CLAUDE.md (Lektion 4) Szenario 2 → Business-Logik in CLAUDE.md (Lektion 4) Szenario 3 → Security-Requirements in CLAUDE.md (Lektion 4) Szenario 4 → /compact + Session Management (diese Lektion) Die Zeit die du in Kontext-Dokumentation investierst, sparst du VIELFACH bei jeder einzelnen Aufgabe.

Kontext-Hierarchie — Wann brauche ich was?

Nicht jedes Projekt und nicht jede Aufgabe braucht den vollen Context-Engineering-Stack. Die richtige Menge an Kontext hängt von der Größe, Komplexität und Kritikalität deiner Arbeit ab. Hier ist ein Stufenmodell das dir hilft die richtige Balance zu finden. Stufe 1 — Einmal-Skripte und Quick Tasks: Minimaler Kontext nötig. Keine CLAUDE.md, keine .claudeignore, keine Skills. Du startest Claude Code, gibst einen konkreten Prompt, und bekommst ein Ergebnis. Perfekt für: Einmalige Analyse, schnelle Code-Generierung, Fragen beantworten. Stufe 2 — Kleine Projekte (1-10 Dateien): Eine kurze CLAUDE.md mit Tech-Stack und 3-5 Konventionen. Vielleicht eine .claudeignore für offensichtliche Excludes. Context-Monitoring mit gelegentlichem /compact. Perfekt für: Persönliche Tools, kleine Websites, Prototypen. Stufe 3 — Mittlere Projekte (10-100 Dateien): Vollständige CLAUDE.md mit allen relevanten Abschnitten. .claudeignore für optimales Scanning. 2-3 Skills für häufige Workflows. Regelmäßiges /compact. Gezielte Nutzung von --include. Perfekt für: Web-Apps, APIs, Team-Projekte. Stufe 4 — Große Projekte (100+ Dateien): Alles aus Stufe 3 plus: Modulare CLAUDE.md Hierarchie, Subagent-Strategie für Exploration, Session-Segmentierung für verschiedene Tasks, aggressives Context-Budget-Management. Perfekt für: Monorepos, Enterprise-Apps, Microservice-Architekturen. Stufe 5 — Enterprise (1000+ Dateien, mehrere Teams): Alles aus Stufe 4 plus: Team-standardisierte Skills und Commands, Multi-Agent-Workflows, CI/CD-Integration, Kosten-Monitoring auf Team-Ebene. Perfekt für: Große Engineering-Organisationen. Die Progression ist organisch: Starte auf der Stufe die deinem Projekt entspricht und erweitere bei Bedarf. Du wirst natürlich zu höheren Stufen wachsen wenn das Projekt komplexer wird.

KONTEXT-HIERARCHIE NACH PROJEKTGRÖSSE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📄 EINMALIGES SKRIPT (50-200 Zeilen)
   Benötigt:
   ✅ Tech Stack ("Python 3.11, keine externen Deps")
   ✅ Ziel ("Konvertiere CSV zu JSON, Encoding: UTF-8")
   Optional:
   ⚪ CLAUDE.md (nicht nötig für ein Skript)

📦 KLEINE APP (1.000-5.000 Zeilen)
   Benötigt:
   ✅ Projekt-Identität (Was? Für wen? Stadium?)
   ✅ Tech Stack + Coding Standards
   ✅ Anti-Patterns
   ✅ .claudeignore
   Optional:
   ⚪ Domain-Logik (wenn simpel)
   ⚪ Feature-Template

🏢 PRODUCTION APP (5.000-50.000 Zeilen)
   Benötigt:
   ✅ ALLES von oben, plus:
   ✅ Architektur-Entscheidungen (ADRs)
   ✅ Domain & Business-Logik
   ✅ Security & Performance Requirements
   ✅ Test-Strategie
   ✅ Development Workflow & DoD
   ✅ Integration-Details (APIs, Limits, Retry)

🏗️ ENTERPRISE (>50.000 Zeilen / Multi-Team)
   Benötigt:
   ✅ ALLES von oben, plus:
   ✅ Compliance (DSGVO, ISO, SOC2)
   ✅ Ordner-spezifische CLAUDE.md
   ✅ Feature-Development Templates
   ✅ ADR-Historie
   ✅ Team-Konventionen

Context Engineering Checkliste

Praktische Übungen

Theorie ohne Praxis ist wertlos. Hier sind drei praktische Übungen die du sofort durchführen kannst um dein Context-Engineering zu verbessern. Jede Übung dauert 15-30 Minuten und hat einen messbaren Effekt auf deine tägliche Arbeit mit Claude Code. Übung 1 — Context-Audit: Starte eine Claude Code Session in deinem aktuellen Projekt. Tippe sofort /context. Notiere: Wie viel Prozent ist belegt? Wovon? Jetzt tippe /cost. Wie viele Tokens hat allein das Laden verbraucht? Ziel: Verstehe deinen Basis-Verbrauch und identifiziere die größten Kontext-Fresser (meist MCP Server und fehlende .claudeignore). Übung 2 — CLAUDE.md Challenge: Nimm dein aktuelles Projekt und erstelle (oder verbessere) die CLAUDE.md. Nutze den Stufenaufbau aus Lektion 4: Projekt-Identität, Tech-Stack, Konventionen, Anti-Patterns. Dann teste: Stelle Claude die gleiche Aufgabe mit und ohne CLAUDE.md und vergleiche die Ergebnisse. Der Unterschied wird dich überzeugen. Übung 3 — Context Rot Experiment: Starte eine Session und arbeite bewusst OHNE /compact. Beobachte ab Nachricht 20 die Qualität. Achte auf die Warnsignale: Widerspricht sich Claude? Vergisst es Konventionen? Wird der Code-Stil inkonsistent? Notiere ab welcher Nachricht du Probleme bemerkst. Dann starte eine neue Session und nutze /compact alle 15 Nachrichten. Vergleiche die Konsistenz. Bonus-Übung — Subagent-Isolation: Bitte Claude eine explorative Aufgabe (z.B. 'Finde alle TODO-Kommentare im Projekt') einmal direkt und einmal per Subagent auszuführen. Vergleiche: Wie viel Kontext verbraucht die direkte Ausführung? Wie viel die Subagent-Ausführung? Der Unterschied demonstriert die Macht von ISOLATE. Diese Übungen sind der Startpunkt. Mache sie zur Gewohnheit — wöchentliches Context-Audit, regelmäßige CLAUDE.md Updates, und bewusstes Monitoring deines Context-Verbrauchs.

ÜBUNG 1: KONTEXT-AUDIT EINES BESTEHENDEN PROJEKTS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Nimm ein eigenes Projekt und prüfe:

□ Hat das Projekt eine CLAUDE.md?
  → Wenn ja: Enthält sie ALLE relevanten Abschnitte?
  → Wenn nein: Was würde Claude falsch annehmen?

□ Identifiziere 3 Stellen wo Claude ohne CLAUDE.md
  die FALSCHE Entscheidung treffen würde:
  - Framework-Wahl?
  - Code-Style?
  - Architektur-Pattern?

□ Gibt es eine .claudeignore?
  → Welche Ordner sind unnötig groß?
  → Welche Dateien enthalten Secrets?

□ Schätze den Token-Verbrauch:
  → Wie viele Dateien hat das Projekt?
  → Wie viel % des Context Windows wären belegt?
ÜBUNG 2: CLAUDE.md VON GRUND AUF ERSTELLEN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Wähle ein Projekt und erstelle eine vollständige CLAUDE.md.
Nutze die Checkliste aus Lektion 4:

1. Projekt-Identität definieren (5 Min)
   → Was? Für wen? Stadium?

2. Technische Constraints auflisten (5 Min)
   → Hard Constraints + WARUM
   → Soft Constraints + Präferenzen

3. Top-3 Architektur-Entscheidungen dokumentieren (10 Min)
   → Was? Warum? Was NICHT?

4. Domain-spezifisches Wissen erfassen (10 Min)
   → Rollen? Geschäftsregeln? Compliance?

5. Workflow festlegen (5 Min)
   → Definition of Done, Git-Conventions

BEWERTUNGSKRITERIEN:
✅ Könnte ein neuer Entwickler damit arbeiten?
✅ Würde Claude damit production-ready Code schreiben?
✅ Sind ALLE kritischen Entscheidungen dokumentiert?
ÜBUNG 3: CONTEXT ROT SIMULIEREN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Starte eine Claude Code Session und beobachte:

1. Starte mit einem Feature: "Implementiere User-Login"
2. Lass Claude implementieren, diskutiere 15+ Nachrichten
3. Beobachte /cost — wie füllt sich der Context?
4. Achte auf die Warnsignale:
   - Wiederholt Claude sich?
   - Liest Claude Dateien nochmal?
   - Vergisst Claude kürzliche Entscheidungen?

5. Bei ~50% Context: /compact ausführen
   → Wie viel wurde eingespart?
   → Wurde Wichtiges beibehalten?

6. Notiere: Bei welchem %-Wert wurden die
   ersten Warnsignale sichtbar?

LERNZIEL: Du entwickelst ein Gespür dafür,
WANN du eingreifen musst — bevor es zu spät ist.

Messbare Lern-Outcomes