Context Engineering in Claude Code: 5 Ebenen gegen Context Rot

Du nutzt Claude Code für ein größeres Projekt, die Anforderungen werden mehr, die Codebase wächst, und plötzlich wirkt dein Coding Agent vergesslich. In diesem Artikel zeige ich dir, woher das Problem kommt und wie du deinen Kontext über fünf Ebenen so aufteilst, dass Claude fokussiert bleibt.

Was ist Context Rot?

Das Phänomen hat einen Namen: Context Rot. Die Leistungsfähigkeit von Large Language Models nimmt systematisch ab, je mehr Informationen im Kontextfenster liegen. Das Kontextfenster ist alles, was Claude in einer Session gerade „im Kopf“ hat: deine Nachrichten, gelesene Dateien, Ausgaben von Befehlen.

Die Folgen kennst du wahrscheinlich: Claude macht Änderungen, wo er keine machen soll, vergisst Entscheidungen von vor einer Stunde und wird insgesamt unzuverlässiger.

Was ist Context Engineering?

Die Antwort auf Context Rot heißt Context Engineering. Gemeint ist die Architektur deines Kontextmanagements: Wie stellst du sicher, dass Claude Code immer genau den Kontext hat, den er gerade braucht, nicht mehr und nicht weniger?

Es geht also ausdrücklich nicht darum, Claude möglichst viel Kontext zu geben. Eher im Gegenteil. Die ETH Zürich hat untersucht, wie Instruktionsdateien wie die CLAUDE.md oder die AGENTS.md anderer Coding Agents die Ergebnisse beeinflussen. Zwei Erkenntnisse daraus:

• Zu viele Anweisungen machen die Aufgabe für den Agenten komplexer. Er exploriert mehr, denkt länger nach und braucht mehr Schritte bis zum Ergebnis. Das gilt nicht nur für Claude Code, sondern auch für GitHub Copilot, Cursor und andere.
• Automatisch generierte Kontextdateien verschlechtern die Leistung im Schnitt sogar leicht. Die Empfehlung lautet deshalb, solche Dateien von Hand zu schreiben.

Zwei Grundregeln für deinen Kontext

Bevor wir uns die fünf Ebenen anschauen, zwei Regeln, die du verinnerlichen solltest.

1. Projektstatus gehört in Dateien, nicht ins Gedächtnis

Wenn dein Kontextfenster voll ist, fasst Claude Code den bisherigen Gesprächsverlauf automatisch zusammen und arbeitet nur noch mit dieser Zusammenfassung weiter. Das nennt sich Compaction oder Verdichtung. Dabei fallen kleine Entscheidungen und Detailinformationen gern hinten runter.

Deshalb gehört alles Wichtige in Markdown-Dateien, die Claude bei Bedarf wieder einlesen kann: Anforderungen, Entscheidungen, der Status deiner Features. Wenn du eine laufende Session sauber an eine neue übergeben willst, statt dich auf die Compaction zu verlassen, schau dir den Handoff-Skill gegen Context Rot an.

2. Nicht alles muss immer geladen sein

Deinen Tech Stack und die Projektbeschreibung sollte Claude in jeder Session kennen. Die Anforderungen an ein bestimmtes Feature oder deine Testing-Konventionen braucht er dagegen nur, wenn er gerade genau daran arbeitet.

Sind solche Informationen immer geladen, füllen sie unnötig dein Kontextfenster und lenken Claude im schlimmsten Fall von der eigentlichen Arbeit ab. Teile deinen Kontext deshalb in Ebenen auf: Manches ist immer da, anderes wird erst geladen, wenn es relevant wird.

Die 5 Ebenen des Kontexts in Claude Code

Als Beispiel nutze ich mein eigenes Entwicklungs-Setup. Darin simuliere ich ein kleines Entwicklungsteam mit verschiedenen Rollen und nutze alle fünf Ebenen.

Ebene 1: Die CLAUDE.md als Fundament

Die CLAUDE.md ist eine Markdown-Datei, die Claude Code bei jeder Session automatisch lädt. Sie liegt im Hauptverzeichnis deines Projekts. Im Kern braucht sie vier Dinge:

1. Projektbeschreibung: Was ist das Projekt, was soll es am Ende tun? Ein bis drei Sätze reichen. Claude braucht nur die Grundidee, um im richtigen Rahmen zu denken.
2. Tech Stack: Welche Frameworks, welches Styling, welche Datenbank, welche Deployment-Plattform. So wählt Claude die richtigen Werkzeuge.
3. Projektstruktur: Wo liegt was? Das lohnt sich besonders, wenn du vom Standard abweichst, und gibt Orientierung, wenn das Projekt größer wird.
4. Allgemeine Verhaltensregeln: Wie läuft der Entwicklungsablauf, wie werden Features getrackt, welche Konventionen gelten, wo findet Claude welche Inhalte.

So sieht das in meinem Setup in gekürzter Form aus:

# Projektname

> Next.js-App mit einem Entwicklungsablauf aus spezialisierten Skills
> für Anforderungen, Architektur, Frontend, Backend, QA und Deployment.

## Tech Stack
- Framework: Next.js (App Router), TypeScript
- Styling: Tailwind CSS + shadcn/ui
- Backend: Supabase (PostgreSQL + Auth + Storage)
- Deployment: Vercel

## Projektstruktur
src/app/          Seiten
src/components/   UI-Komponenten
features/         Feature-Spezifikationen (PROJ-X-name.md)
features/INDEX.md Status-Übersicht aller Features

## Entwicklungsablauf
1. /requirements  Feature-Spezifikation schreiben
2. /architecture  Technische Architektur planen
3. /frontend      UI bauen
4. /backend       APIs und Datenbank
5. /qa            Gegen Akzeptanzkriterien testen
6. /deploy        Deployment

## Konventionen
- Eine Spezifikation pro Feature
- Commits: feat(PROJ-X): Beschreibung
- Vor jeder Freigabe fragt Claude nach

Eine Regel, die ich jedem empfehle: Lesen statt raten

Ergänze eine Anweisung, dass Claude Dateien immer liest und niemals rät. Stell dir vor, Claude hat vor einer Weile mit einer Datei gearbeitet und soll jetzt auf dieser Basis eine andere ändern. Hat er die erste nicht noch einmal gelesen, glaubt er vielleicht, alle Informationen noch im Kontext zu haben. Ist das nicht der Fall, trifft er Annahmen und beginnt zu halluzinieren.

Lies eine Datei immer, bevor du auf ihren Inhalt Bezug nimmst oder sie änderst. Triff keine Annahmen über Dateiinhalte aus dem Gedächtnis.

Halte die CLAUDE.md kurz

Im Idealfall ist die Datei nicht länger als eine Seite. Das deckt sich mit der Studie: Zu viel Kontext verschlechtert das Ergebnis eher. Frag dich, was Claude wirklich bei jeder Aufgabe wissen muss. Alles andere lagerst du in die anderen Ebenen aus.

Achtung bei Verweisen: Bindest du mit @docs/PRD.md eine andere Datei in die CLAUDE.md ein, wird auch diese bei jeder Session vollständig geladen. Lange Dokumente referenzierst du deshalb lieber in Skills, die sie nur bei Bedarf lesen.

Mehrere CLAUDE.md-Dateien

Du bist nicht auf eine Datei beschränkt:

• Eine globale CLAUDE.md unter ~/.claude/CLAUDE.md gilt für alle deine Projekte.
• Die Projekt-CLAUDE.md im Hauptverzeichnis gilt für dieses Projekt.
• In größeren Projekten kannst du zusätzliche CLAUDE.md-Dateien in Unterordnern ablegen. Die liest Claude erst, wenn er in diesem Bereich arbeitet.

Ebene 2: Rules für Konventionen je Bereich

Rules (Regeln) werden ebenfalls automatisch geladen, aber nur, wenn Claude in bestimmten Bereichen arbeitet. Sie liegen im Ordner .claude/rules/ deines Projekts und sind wieder einfache Markdown-Dateien.

Ein Beispiel: In meinem Setup arbeite ich mit Feature-Spezifikationen. Das sind Markdown-Dateien, die beschreiben, was ein Feature tun soll, welche Akzeptanzkriterien gelten und welche Sonderfälle (Edge Cases) zu berücksichtigen sind. Für diese Specs habe ich Konventionen, etwa dass Akzeptanzkriterien im Given/When/Then-Format stehen. Diese Konventionen sollen nur gelten, wenn Claude an einer Spec arbeitet, nicht wenn er UI-Komponenten baut oder Tests schreibt.

Eine Rule besteht aus einem Header und den eigentlichen Regeln. Im Header legst du mit paths fest, für welche Dateien sie gilt:

---
paths:
  - "features/**/*.md"
---

# Konventionen für Feature-Spezifikationen

- Jede Spec braucht eine klare Problembeschreibung
- Akzeptanzkriterien im Given/When/Then-Format
- Technische Entscheidungen müssen begründet sein
- Kein Feature ohne definierte Edge Cases

Sobald Claude eine Datei liest, die auf das Muster passt, hat er diese Konventionen im Kontext. Bei allem anderen bleiben sie draußen. Du kannst Rules als flexible Erweiterung der CLAUDE.md sehen.

Rule oder Skill?

Vielleicht fragst du dich: Könnte ich die Konventionen nicht auch in einen Skill schreiben? Grundsätzlich ja. Du musst von Fall zu Fall abwägen.

In meinem Fall arbeiten mehrere Skills mit Feature-Specs, etwa der Requirements-Skill und der QA-Skill. Stünden die Konventionen in jedem dieser Skills, müsste ich bei jeder Änderung alle Skills anpassen. Als Rule definiere ich sie einmal, und sie gilt automatisch überall. Selbst wenn ich Claude nur kurz bitte, die Akzeptanzkriterien von Feature 3 zu aktualisieren, und er dafür gar keinen Skill aufruft, hat er die Konventionen im Kontext.

Rules ohne Pfad sparsam einsetzen

Lässt du paths weg, wird die Rule immer geladen, wie eine direkte Erweiterung der CLAUDE.md. Für allgemeine Projektregeln kann das sinnvoll sein. Übertreib es aber nicht: Zehn Rule-Dateien, die zusätzlich zur CLAUDE.md immer geladen werden, bringen dich zurück zum Ausgangsproblem.

Ebene 3: Skills als wiederverwendbare Arbeitsanleitungen

Skills sind Anleitungen oder wiederverwendbare Workflows für Claude Code. Damit bringst du Claude bei, wie er nach deinen Vorgaben programmiert, designt, Anforderungsdokumente erstellt oder Marketingmaterial schreibt.

Ein Skill wird auf zwei Arten geladen:

• Explizit: Jeder Skill ist als Slash Command verfügbar. Du tippst / und bekommst eine Liste der verfügbaren Skills.
• Automatisch: Claude entscheidet selbst, dass ein Skill für die aktuelle Aufgabe sinnvoll ist.

Technisch ist ein Skill ein Ordner unter .claude/skills/ mit einer Datei SKILL.md. Für die Kontextfrage ist vor allem eines wichtig: Claude liest beim Suchen nach passenden Skills nur den Header mit Name und Beschreibung. Erst wenn er sich für einen Skill entscheidet, lädt er den Rest. Das spart Token und hält den Kontext schlank. Umso wichtiger ist eine klare Beschreibung.

Im Inhalt kannst du Claude in eine Rolle versetzen und ihm genaue Arbeitsanweisungen geben. Mein Deployment-Skill macht Claude zum DevOps Engineer: Erst liest er bestimmte Dateien und prüft Voraussetzungen, dann arbeitet er eine Checkliste Punkt für Punkt ab. Zusätzlich kannst du Beispiele und Referenzdateien mitgeben.

Wie du Skills aufbaust, Header-Felder nutzt und eigene Skills erstellst, erkläre ich ausführlich im Guide zu Agent Skills in Claude Code.

Ebene 4: Subagents mit eigenem Kontextfenster

Du kannst Claude jederzeit bitten, eine oder mehrere Aufgaben an Subagents zu geben. Ein Subagent läuft in einem eigenen Kontextfenster, komplett losgelöst vom Hauptagenten. Er weiß nichts von dem, was du gerade in deiner Hauptsession machst.

Ansonsten kann ein Subagent alles, was dein Hauptagent auch kann: Dateien lesen und schreiben, Code ausführen, im Web recherchieren, die Codebase durchsuchen. So läuft das ab:

1. Du gibst Claude eine Aufgabe und sagst, dass er Subagents nutzen soll.
2. Claude startet die Subagents und gibt jedem einen Prompt mit seiner Teilaufgabe.
3. Jeder Subagent arbeitet in seinem eigenen Kontext.
4. Am Ende schickt er eine einzige Nachricht mit Ergebnissen und Zusammenfassung zurück.
5. Der Hauptagent arbeitet nur mit dieser Zusammenfassung weiter.

Genau das macht Subagents für Context Engineering so wertvoll: Die ganze Detailarbeit landet nicht im Kontext deiner Hauptsession.

In meinem Setup nutze ich Subagents für die eigentliche Entwicklungsarbeit: einen Frontend Developer, einen Backend Developer und einen QA Engineer, der am Ende die Qualität prüft. Jeder hat seine eigene Rolle, seine eigenen Werkzeuge und Anweisungen. Der Frontend-Subagent weiß zum Beispiel, dass wir mit React, Next.js, Tailwind und shadcn/ui arbeiten. Eigene Subagents legst du als Markdown-Dateien im Ordner .claude/agents/ an.

Subagents können auch parallel laufen. Habe ich mehrere Frontend-Komponenten, die unabhängig voneinander entstehen können, starte ich sie gleichzeitig.

Subagents vs. Agent Teams

Anthropic hat mit Agent Teams ein Feature für Claude Code veröffentlicht, das auf einer ähnlichen Mechanik aufbaut: Mehrere Agenten laufen parallel. Das Ziel ist aber ein anderes. Bei Agent Teams geht es um verschiedene Perspektiven auf dasselbe Problem.

Ein Beispiel: Ein Agent reviewt deinen Code als Developer, ein zweiter durch die Security-Brille, ein dritter prüft die Architektur. Die Agenten stimmen sich untereinander ab und widersprechen sich teilweise. Genau das ist gewollt, denn so deckst du blinde Flecken auf.

Ebene 5: MCP Server für externe Systeme

MCP steht für Model Context Protocol. Es dient Claude Code als universelle Schnittstelle zu externen Tools und Diensten.

Einen MCP Server musst du einmal konfigurieren. Je nach Dienst brauchst du dafür einen API-Schlüssel oder eine URL. Am einfachsten sagst du Claude, welchen MCP Server er anbinden soll. Er übernimmt die Konfiguration, legt die nötige Einstellungsdatei an und fragt dich nur nach den Informationen, die er braucht.

Drei MCP Server nutze ich regelmäßig:

• Context7: Damit greift Claude auf aktuelle Dokumentation von Frameworks und Schnittstellen zu, statt sich auf veraltetes Wissen aus seinem Training zu verlassen. Das verhindert viele Bugs schon bei der Implementierung.
• Supabase: Supabase ist ein Backend as a Service, also Datenbank, Benutzer-Login und Speicher aus einer Hand. Über den MCP Server legt Claude direkt Tabellen an, befüllt sie, führt Abfragen aus und kümmert sich um die Backend-Umsetzung.
• Figma: Ich starte Webanwendungen gern mit einem Design in Figma. Über den MCP Server bekommt Claude Zugriff auf meine Layouts und setzt sie detailgetreu um.

Zusammenfassung: Jede Information auf ihrer Ebene

Context Engineering ist deine Architektur dafür, wie du Kontext managst. Die fünf Ebenen in Claude Code helfen dir, Claude fokussiert zu halten und Context Rot zu vermeiden:

• CLAUDE.md: Alles, was zum Start jeder Session wichtig ist. Global, im Projekt und in Unterordnern möglich. Kurz und schlank halten.
• Rules: Ergänzende Konventionen, die automatisch je nach Arbeitsbereich aktiv werden.
• Skills: Arbeitsanleitungen, die bei Bedarf geladen werden, per Slash Command oder durch Claudes eigene Wahl.
• Subagents: Helfer mit isoliertem Kontext für fokussierte Teilaufgaben.
• MCP Server: Die Verbindung zu externen Systemen.

Je größer dein Projekt wird, desto wichtiger wird diese Struktur. Für Software, die du wirklich betreiben oder verkaufen willst, reicht sie allein aber nicht: Dann brauchst du zusätzlich einen festen Entwicklungsprozess, in dem jedes Feature dieselben Schritte durchläuft, von der Spezifikation bis zur Prüfung.