Ich habe bereits darüber geschrieben, wie man am besten die neueste Generation der Claude 5 Modelle promptet und iterativ mit ihnen arbeitet, um herauszufinden, was man bauen möchte.
Aber wenn du eine Nachricht an Claude sendest, ist der Prompt nur ein kleiner Teil des Kontexts, den es erhält. Ein Großteil deines Kontexts wird aus deinem System-Prompt, Skills, CLAUDE.md-Dateien, Memory und anderen Quellen zusammengestellt. Wir nennen das Context Engineering, und es hat einen großen Einfluss auf die Ergebnisse, die du mit Claude Code erzielst oder wenn du deine eigenen Agenten baust.
Im Gegensatz zu einem Prompt wird Context allgemein über viele Anfragen hinweg verwendet, kann also nicht so spezifisch sein. Wie erstellst du diese allgemeinen Prompts und Anleitungen für Claude, besonders wenn du nicht weißt, was der Prompt eines Benutzers sein könnte?
Das kann überraschend schwierig sein, da sich Claudes eigene Fähigkeiten weiterentwickeln. Kürzlich haben wir einen großen Sprung in der Art und Weise festgestellt, wie wir die neueste Generation von Claude-Modellen prompten. Wir haben über 80 % des System-Prompts von Claude Code für Modelle wie Claude Opus 5 und Claude Fable 5 entfernt, ohne messbare Verluste in unseren Code-Bewertungen.
Hier ist, was wir über das Prompten dieser neuen Modellklasse gelernt haben und wie du es nutzen kannst, um dein Context Engineering zu aktualisieren. Wir haben diese Best Practices in claude doctor eingebaut – verwende den Befehl /doctor in Claude Code, um deine Skills und CLAUDE.md-Dateien richtig auszurichten.
Claude entfesseln
Insgesamt haben wir festgestellt, dass wir Claude Code übermäßig eingeschränkt haben – sowohl durch unseren System-Prompt als auch in unseren CLAUDE.md-Dateien und Skills.
Wenn wir zum Beispiel Transkripte unserer eigenen internen Nutzung von Claude Code lesen, sehen wir mehrere widersprüchliche Anweisungen in einer einzigen Anfrage, wie „Dokumentation nach eigenem Ermessen hinterlassen“ oder „Füge KEINE Kommentare hinzu“, da unser System-Prompt, Skills und Benutzeranfragen miteinander kollidieren.
Im Allgemeinen kann Claude die Absicht des Benutzers interpretieren, um zur richtigen Antwort zu gelangen, aber Claude muss sorgfältiger über diese überlappenden und widersprüchlichen Nachrichten nachdenken, bevor es entscheidet, was zu tun ist.
Und obwohl diese Einschränkungen einst notwendig waren, um Worst-Case-Szenarien zu vermeiden, haben wir inzwischen festgestellt, dass wir viele davon löschen und dem Modell stattdessen erlauben können, den umgebenden Kontext und sein eigenes Urteilsvermögen zu nutzen.
Außerdem hat Claude Code jetzt viel mehr Werkzeuge. Früher war Claude auf CLAUDE.md als Quelle für Memory, Informationen und Anleitungen angewiesen. Jetzt haben wir Memory, Artifacts und Skills, mit denen Claude neue Wege zum Laden und Teilen von Kontext über Sitzungen hinweg erstellen kann.
Früher und heute
Es gab eine Reihe von früheren Best Practices im Context Engineering, die zu Mythen geworden waren. Dazu gehören:
**
Früher: Claude Regeln geben
Heute: Claude sein Urteilsvermögen nutzen lassen
**Als wir Claude Code zum ersten Mal eingeführt haben, mussten wir sicherstellen, dass Claude Worst-Case-Szenarien wie das Löschen von Dateien vermeidet. Das bedeutete, dass wir besonders strenge Anweisungen gaben, die nicht immer zutreffen mussten. Zum Beispiel hieß es im System-Prompt früher:
In Code: standardmäßig keine Kommentare schreiben. Niemals mehrteilige Docstrings oder mehrzeilige Kommentarblöcke schreiben – maximal eine kurze Zeile. Keine Planungs-, Entscheidungs- oder Analysedokumente erstellen, es sei denn, der Benutzer fragt danach – aus dem Gesprächskontext arbeiten, nicht aus Zwischendateien.
Aber für eine bestimmte Teilmenge von Prompts war diese Anweisung falsch. Im Fall von Dokumentation könnte der Benutzer eigene Vorlieben haben, oder bestimmte Teile von sehr komplexem Code könnten mehrzeilige Kommentarblöcke erfordern.
Trotzdem wären ohne diese Schutzmaßnahmen für ältere Modelle die Kommentare, die Claude schrieb, in vielen Fällen falsch gewesen, und wir mussten diesen Kompromiss akzeptieren. Neuere Modelle haben jedoch ein besseres Urteilsvermögen und können diese Entscheidungen ohne explizite Regeln gut treffen.
Im neuen System-Prompt sagen wir: Schreibe Code, der wie der umgebende Code liest: gleiche Kommentardichte, Benennung und Sprachstil.
**Früher: Claude Beispiele geben
Heute: Schnittstellen entwerfen
**Die wichtigste Regel für die Werkzeugnutzung war, Claude Beispiele für deren Verwendung zu geben. Mit unseren neuesten Modellen haben wir festgestellt, dass Beispiele sie tatsächlich auf einen bestimmten Erkundungsraum einschränken.
Denke statt Beispielen mehr über das Design deiner Werkzeuge, Skripte und Dateien nach – welche Parameter hat Claude und wie können sie ausdrucksstärker sein?
Zum Beispiel gibt im Todo-Tool-Beispiel bereits die Auflistung des Status als Aufzählung zwischen „pending“, „in_progress“ und „completed“ Claude einen Hinweis, wie es verwendet werden soll. Die Anweisung, ein Element „in_progress“ zu halten, hilft, das gewünschte Verhalten zu definieren.
**Früher: Alles auf einmal vorneweg
Heute: Progressive Offenlegung verwenden**
Da Claude Code auf das Programmieren fokussiert war, enthielt unser System-Prompt detaillierte Informationen zur Durchführung von Code-Reviews und Verifikation. Diese waren nicht immer nötig, aber wenn sie es waren, war es entscheidende Information.
Seitdem ist Claude Code sehr kompetent im Umgang mit progressiver Offenlegung geworden – den richtigen Kontext zur richtigen Zeit zu laden. Zum Beispiel haben wir Verifikation und Code-Review in eigene Skills ausgelagert, die Claude Code selektiv aufrufen kann.
Aber progressive Offenlegung gilt nicht nur für Skills, wir verwenden sie auch für Werkzeuge. Einige unserer Werkzeuge werden „verzögert geladen“, was bedeutet, dass der Agent nach ihren vollständigen Definitionen mit ToolSearch suchen muss, bevor er sie verwendet. Das ermöglicht es uns, mehr Werkzeuge (wie unsere Task-Werkzeuge) zu haben, die erst dann Kontext belegen, wenn sie gebraucht werden.
Das Gleiche kannst du auf deine eigenen CLAUDE.md- und Skill.md-Dateien anwenden. Ein verbreiteter Mythos ist, dass du diese zu einem zentralen Repository für jede bekannte Praxis machen solltest, auf die du eventuell stößt, weil Claude sie sonst nicht finden würde. Stattdessen solltest du einen Baum von Dateien in Betracht ziehen, die zur richtigen Zeit geladen werden können.
**Früher: Wiederhole dich
Heute: Einfache Werkzeugbeschreibungen**
Frühere Claude-Modelle brauchten manchmal wiederholte Anweisungen oder hörten eher auf Anweisungen am Ende ihres Kontextfensters als am Anfang. Das bedeutete, dass unser System-Prompt manchmal sowohl Verweise auf Werkzeuge im Haupt-System-Prompt als auch Anweisungen in der Werkzeugbeschreibung enthielt.
Wir haben festgestellt, dass wir diese sich wiederholenden Beispiele löschen und die Anweisungen zur Verwendung von Werkzeugen in die Werkzeugbeschreibungen statt in den System-Prompt setzen können.
**Früher: Memory in CLAUDE.md-Dateien
Heute: Auto-Memory**
Früher haben wir Benutzer ermutigt, Dinge in Claudes Memory zu speichern, indem sie den #-Hotkey verwenden, um automatisch in ihre CLAUDE.md-Datei zu schreiben. Stattdessen speichert Claude jetzt automatisch Erinnerungen, die für die Arbeit und für dich relevant sind.
**Früher: Einfache Spezifikationen
Heute: Reichhaltige Referenzen**
Im Plan-Modus hat Claude Code stark auf Markdown-Dateien mit Plänen zurückgegriffen. Das Speichern dieser Dateien als Pläne half Claude, bei Bedarf darauf zu verweisen. Eine weitere ähnliche Best Practice war, Spezifikationen im Codebase zu speichern, damit Claude bei längeren Projekten darauf zurückgreifen kann.
Aber wir haben festgestellt, dass Claude mit zunehmend komplexeren Referenzen umgehen kann. Statt einfacher Markdown-Dateien kann Claude auf HTML-Artifacts verweisen, die mit unserer neuen Artifacts-Funktion erstellt wurden.
Du kannst Claude auch Referenzen in Form von Code geben. Eine Spezifikation kann auch eine detaillierte Testsuite oder eine Funktion in einem anderen Codebase sein, die Claude möglicherweise portiert.
Rubriken sind eine weitere Form von Referenzen. Rubriken erlauben es Claude, deinen Geschmack in einem bestimmten Bereich zu testen und zu verifizieren (z. B. wie ein gutes API-Design aussieht), indem es dynamische Workflows verwendet und Verifizierer-Agenten mit diesen Rubriken startet.
Dies auf deinen Kontext anwenden
Wie sieht das nun aus, wenn du deinen Kontext zusammenstellst?
**System-Prompt
**Ein System-Prompt ist stark an den Produktkontext gebunden. Er sagt Claude, in welchem Produkt es arbeitet und was es tut. Für Claude Code wirst du diesen wahrscheinlich nie ändern, aber wenn du deine eigene Agenten-Umgebung baust, solltest du hier viel Zeit investieren.
**CLAUDE.md
**Halte deine CLAUDE.md leichtgewichtig und beschreibe kurz, wofür dein Repository ist, aber verwende die meisten Tokens für Fallstricke innerhalb des Codebases. Zum Beispiel könntest du deinen Code so organisieren, dass Typen in einer einzigen monolithischen Datei und nirgendwo anders gespeichert werden. Vermeide es, das „Offensichtliche“ zu erwähnen, das Claude durch einen Blick auf dein Dateisystem oder dein Repository wissen sollte.
Verwende progressive Offenlegung für weitere Details. Wenn du zum Beispiel mehrere einzigartige Anweisungen zur Überprüfung deiner Arbeit hast, erstelle einen Verifikations-Skill und verweise von deiner CLAUDE.md darauf.
**Skills
**Betrachte Skills als leichtgewichtige Anleitungen, die Claude helfen, bei Bedarf Informationen zu finden. Vermeide es, sie übermäßig einzuschränken, außer in sehr wichtigen Bereichen.
Versuche bei langen Skills, so viel progressive Offenlegung wie möglich zu verwenden – teile sie in viele Dateien auf und gliedere sie aus.
Am besten ist es, wenn Skills bestimmte Meinungen, Kenntnisse oder Best Practices kodieren, die für dich, dein Team oder dein Produkt spezifisch sind.
**Referenzen
**Du kannst Dateien mit @ erwähnen, um sie als Referenzen einzubinden. Referenzen erlauben Claude, auf detaillierte Informationen zum aktuellen Plan zurückzugreifen.
Dies kann in Spezifikationsdateien, Mockups oder sogar ganzen Codebasen sein. Im Allgemeinen solltest du Dateien bevorzugen, die in Code vorliegen, da sie Claude klare, hochpräzise Anweisungen in einer Sprache geben, die es sehr gut kennt. Zum Beispiel wird ein HTML-Mockup eines Designs in der Regel bessere Ergebnisse liefern als eine Beschreibung des Designs oder ein Screenshot.
Versuche zu vereinfachen
In deinem System-Prompt, Skills und CLAUDE.md-Dateien musst du möglicherweise genauso vereinfachen wie wir. Wir haben einen neuen Befehl namens claude doctor eingeführt, der dir dabei automatisch hilft. Weitere Details zum Prompten speziell fortgeschrittenerer Modelle findest du in unserem Fable Field Guide.
