Neue Regeln für Context Engineering bei Claude-5-Modellen

• Bei Claude Opus 5 und Claude Fable 5 wurde der System Prompt von Claude Code um mehr als 80 % gekürzt, ohne dass es in Coding-Evaluierungen zu einem messbaren Leistungsabfall kam
• Detailregeln, die bei früheren Modellen Worst-Case-Szenarien verhindern sollten, können zwischen System Prompt, Skills, CLAUDE.md und Nutzeranfragen in Konflikt geraten; bei aktuellen Modellen ist es besser, Umgebungskontext und eigenes Urteilsvermögen zu nutzen
• Statt alle Anweisungen und Tool-Beispiele im Voraus bereitzustellen, wird progressive disclosure eingesetzt: ausdrucksstarke Interfaces sowie das Nachladen von Informationen und Tools genau dann, wenn sie gebraucht werden
• Für CLAUDE.md wird empfohlen, nur Fallstricke des Repositories knapp festzuhalten, lange Anweisungen in Skills auszulagern und umfangreiche Referenzmaterialien wie Spezifikationen, Test-Suites, HTML-Mockups, Code und Bewertungsrubriken zu nutzen
• Mit /doctor und claude doctor lassen sich Skills und CLAUDE.md in ihrer Größe anpassen; der Kontext aktueller Modelle sollte Wiederholungen und übermäßige Einschränkungen reduzieren und stattdessen so aufgebaut sein, dass relevante Informationen bei Bedarf gefunden werden

---

Context Engineering jenseits des Prompts

• Wenn Claude Nachrichten verarbeitet, ist der Nutzer-Prompt nur ein Teil des gesamten Kontexts; der Rest wird aus System Prompt, Skills, CLAUDE.md, Memory und weiteren Quellen zusammengesetzt
• Context Engineering gilt über mehrere Anfragen hinweg und ist deshalb schwerer so konkret zu formulieren wie ein einzelner Prompt, hat aber großen Einfluss auf die Ergebnisse von Claude Code und eigenen Agenten
• Allgemeine Prompts und Anweisungen müssen entworfen werden, ohne die künftigen Nutzeranfragen im Voraus zu kennen, und mit den Fortschritten von Claude ändern sich auch die geeigneten Vorgehensweisen
• Bei Claude Opus 5 und Claude Fable 5 konnte mehr als 80 % des Claude-Code-System-Prompts gelöscht werden, ohne dass sich in Coding-Evaluierungen ein messbarer Leistungsabfall zeigte
• Diese Best Practice wurde in claude doctor übernommen; in Claude Code lassen sich Skills und CLAUDE.md per /doctor auf eine angemessene Größe bringen

Das Modell von übermäßigen Einschränkungen befreien

• Früheres Claude Code war nicht nur durch den System Prompt, sondern auch durch CLAUDE.md und Skills übermäßig stark eingeschränkt
  • In einer Anfrage konnten Anweisungen wie „hinterlasse angemessene Dokumentation“ und „füge keine Kommentare hinzu“ über System Prompt, Skills und Nutzeranfrage miteinander kollidieren
  • Selbst wenn Claude die Nutzerabsicht interpretieren konnte, musste es wegen überlappender oder widersprüchlicher Anweisungen vorsichtiger nachdenken, bevor es handelte
• Früher waren solche Einschränkungen nötig, um Worst-Case-Szenarien zu vermeiden, doch aktuelle Modelle können viele dieser Vorgaben entfernen und stattdessen Umgebungskontext und eigenes Urteilsvermögen nutzen
• Auch die Zahl der Tools, die Claude Code verwenden kann, ist gestiegen
  • Früher war CLAUDE.md der wichtigste Speicherort für Memory, Informationen und Anweisungen
  • Heute lassen sich über Memory, Artifacts und Skills Kontexte sitzungsübergreifend laden und teilen

Statt fixer Regeln kontextbasiertes Urteilsvermögen nutzen

• In frühem Claude Code wurden starke, nicht immer passende Anweisungen eingebaut, um Worst-Case-Szenarien wie das Löschen von Dateien zu verhindern
• Der frühere System Prompt verlangte standardmäßig, im Code keine Kommentare zu schreiben, mehrabsätzige Docstrings oder mehrzeilige Kommentare zu vermeiden und ohne ausdrückliche Nutzeranfrage keine Dokumente zu Planung, Entscheidungen oder Analyse anzulegen
• Solche Regeln können bei manchen Anfragen unangemessen sein
  • Nutzer können eigene Dokumentationspräferenzen haben
  • Für bestimmte Teile komplexen Codes können mehrzeilige Kommentare notwendig sein
• Ältere Modelle schrieben ohne Schutzvorkehrungen häufig fehlerhafte Kommentare, weshalb dieser Kompromiss nötig war; aktuelle Modelle treffen solche Entscheidungen auch ohne explizite Regeln besser
• Der neue System Prompt nutzt kontextbasierte Anweisungen wie: „Schreibe Code, der sich wie der umgebende Code liest, und passe Kommentardichte, Benennung und Idiome an“

Ausdrucksstarke Interfaces statt Beispiele entwerfen

• Früher galt es als zentrale Regel für den Tool-Einsatz, Claude Anwendungsbeispiele zu geben
• Bei aktuellen Modellen können Beispiele den Suchraum auf bestimmte Bereiche einschränken; daher sollte die Ausdrucksstärke von Interfaces und Parametern für Tools, Skripte und Dateien priorisiert werden
• Wenn beim Todo-Tool status als Enum pending, in_progress, completed definiert ist, deutet das die Nutzung auf natürliche Weise an
• Die Anweisung, immer nur einen Eintrag als in_progress zu halten, konkretisiert das gewünschte Verhalten auf Interface-Ebene

Progressive Disclosure: Informationen erst im richtigen Moment öffnen

• Als Claude Code anfangs stark auf Coding fokussiert war, wurden Hinweise zu Code Review und Verifikation ausführlich in den System Prompt geschrieben
• Diese Informationen wurden nicht immer benötigt, waren aber bei bestimmten Aufgaben wichtig
• Heute lässt sich progressive disclosure nutzen, um passenden Kontext genau dann zu laden, wenn er gebraucht wird
  • Richtlinien für Verifikation und Code Review werden jeweils in eigene Skills ausgelagert, die Claude Code bei Bedarf selektiv aufruft
  • Einige Tools werden verzögert geladen; der Agent muss vor der Nutzung per ToolSearch die vollständige Definition durchsuchen
  • So können viele Tools wie das Task-Tool bereitgestellt werden, ohne vorab Kontext zu belegen
• CLAUDE.md und Skill.md müssen nicht als zentrales Archiv aller möglichen Praktiken dienen
• Stattdessen können sie als Dateibaum organisiert werden, der bei Bedarf geladen wird; dieser Ansatz wird auch in A Harness for Every Task: Dynamic Workflows in Claude Code behandelt

Wiederholte Anweisungen in einfache Tool-Beschreibungen integrieren

• Frühere Claude-Modelle erforderten teils die Wiederholung derselben Anweisung und befolgten Anweisungen am Ende des Kontexts manchmal besser als solche am Anfang
• Deshalb wurden identische Hinweise oder Beispiele zur Tool-Nutzung sowohl in den Haupttext des System Prompts als auch in Tool-Beschreibungen aufgenommen
• Bei aktuellen Modellen lassen sich solche Wiederholungen entfernen und Hinweise zur Tool-Nutzung nur noch in den Tool-Beschreibungen platzieren

Von CLAUDE.md zu automatischem Memory wechseln

• Früher wurde empfohlen, Informationen per #-Shortcut automatisch in CLAUDE.md zu schreiben, damit Nutzer Claudes Memory direkt selbst speichern konnten
• Heute speichert Claude für Aufgaben und Nutzer relevante Informationen automatisch als Memory

Umfangreiche Referenzmaterialien statt nur einfacher Spezifikationen

• Claude Code im Planungsmodus stützte sich stark auf Markdown-Planungsdateien, um bei Bedarf erneut darauf zu verweisen; bei langfristigen Projekten wurden Spezifikationen teils direkt in der Codebasis gespeichert
• Aktuelle Claude-Modelle können Referenzmaterialien in komplexeren Formaten verarbeiten
  • Mit der neuen Artifact-Funktion erzeugte HTML-Artifacts
  • Code wie Funktionen, die aus anderen Codebasen portiert werden sollen
  • Als detaillierte Test-Suite ausgedrückte Spezifikationen
• Eine Bewertungsrubrik ist eine weitere Referenzform, mit der Claude Geschmacks- oder Qualitätskriterien in einem bestimmten Bereich ausprobieren und überprüfen kann
  • So lässt sich definieren, was gutes API-Design ausmacht
  • Über dynamische Workflows kann ein Verifikationsagent erzeugt werden, der diese Bewertungsrubrik verwendet

Rollen der einzelnen Kontextbausteine

• System Prompt

  • Eng mit dem Produktkontext verbunden und dafür zuständig, Claude zu sagen, in welchem Produkt es welche Aufgabe ausführt
  • Für Nutzer von Claude Code gibt es hier selten etwas anzupassen; wer jedoch ein eigenes Agent-Harness baut, sollte diesem Bereich viel Zeit widmen

• CLAUDE.md

  • Sollte leichtgewichtig bleiben und den Zweck des Repositories kurz beschreiben; der Großteil der Tokens sollte aber dafür genutzt werden, wichtige Fallstricke in der Codebasis festzuhalten
  • Eine Repository-Regel wie „alle Typen nur in einer einzigen Datei“ ist festhaltenswert
  • Offensichtliche Informationen, die Claude durch einen Blick ins Dateisystem oder Repository selbst erkennen kann, sollten vermieden werden
  • Gibt es viele spezifische Hinweise zur Aufgabenverifikation, sollte ein Verifikations-Skill erstellt und aus CLAUDE.md heraus referenziert werden, um progressive disclosure anzuwenden

• Skills

  • Sollten als leichte Wegweiser aufgebaut sein, die Claude helfen, Informationen bei Bedarf zu finden
  • Außer in wirklich kritischen Bereichen sollten übermäßige Einschränkungen vermieden werden
  • Lange Skills sollten lieber auf mehrere Dateien verteilt werden, damit sie schrittweise geladen werden können
  • Besonders nützlich, um persönliche, Team- oder produktspezifische Ansichten, Wissensbestände und Best Practices zu vermitteln

• Referenzmaterialien

  • Wenn Dateien mit @ erwähnt werden, kann Claude detaillierte Informationen prüfen, die für den aktuellen Plan relevant sind
  • Spezifikationsdateien, Mockups und sogar die gesamte Codebasis können Referenzmaterial sein
  • Code liefert klare und präzise Anweisungen in einer Sprache, die Claude gut versteht; deshalb sind im Allgemeinen Dateien in Codeform zu bevorzugen
  • HTML-Design-Mockups liefern in der Regel bessere Ergebnisse als Designbeschreibungen oder Screenshots

Bestehenden Kontext vereinfachen

• Unnötige Regeln, Wiederholungen und Informationen sollten über System Prompt, Skills und CLAUDE.md hinweg entfernt werden, um den Kontext zu vereinfachen
• Der Befehl claude doctor unterstützt diese Vereinfachung automatisch
• Weitere Hinweise zum Prompting fortgeschrittener Modelle gibt der Claude-Fable-Leitfaden aus der Praxis