Prompting hat sich verändert. Unsere Anweisungen größtenteils nicht.

Die Modelle wurden klüger. Unsere Prompt-Stapel wurden älter. Es ist an der Zeit, das Instruktionsmuseum durch eine kleine Karte, klare Grenzen und eine Ziellinie zu ersetzen.

Vor ein paar Tagen ist mir etwas leicht Unangenehmes aufgefallen:

Fast alle meine Prompts, Instruktionsdateien, Regeln und Skills waren veraltet.

Nicht völlig nutzlos. Einfach für eine andere Generation von Modellen geschrieben.

Die Prompt-Stapel, die älteren Modellen halfen, sich zu benehmen, können GPT-5.6, Claude Fable 5, Claude Opus 5, Grok 4.5 und Codierungstools wie Cursor steifer, teurer und manchmal einfach schlechter machen.

Das ist nicht meine neueste Prompt-Religion. Anthropic warnt explizit davor, dass für frühere Modelle geschriebene Skills für Fable 5 zu vorschreibend sein können und die Ausgabequalität verschlechtern können. OpenAI empfiehlt schlankere Prompts, weniger wiederholte Anweisungen und einfachere Tool-Beschreibungen.

Das war leicht peinlich zu lesen.

Seit Sommer 2025 habe ich mehr als 100.000 Prompts geschrieben. Das ist ungefähr Elons Musks Tweet-Zahl seines Lebens, nur mit weniger Raketen und mehr fehlschlagenden Test-Suites.

Meine Logs enthalten rund 15 Millionen Modell-Nachrichten, einschließlich Assistent-Nachrichten, Tool-Aufrufen, Subagenten und Workflow-Ereignissen. Bis zum 26. März waren es etwa sieben Millionen. Weitere acht Millionen kamen innerhalb von drei Monaten hinzu, hauptsächlich aufgrund der Subagenten- und Workflow-Explosion rund um neuere Codierungsmodelle.

Also dachte ich, ich wüsste, wie man Anweisungen schreibt.

Dann las ich die neue Dokumentation und erkannte, dass vieles von dem, was ich gelernt hatte, still und leise zu technischen Schulden geworden war.

Wie Prompt-Schulden entstehen

Mein alter Ansatz war einfach:

• Das Modell machte einen Fehler, also fügte ich eine Regel hinzu.
• Es stellte eine unnötige Frage, also fügte ich eine weitere Regel hinzu.
• Es übersah einen Randfall, also fügte ich drei Beispiele hinzu.

Jede Ergänzung sah für sich genommen vernünftig aus. Nach einem Jahr glich die Instruktionsdatei dieser Küchenschublade, in der man zwölf alte Kabel aufbewahrt, weil eines davon vielleicht noch zu etwas Wichtigem gehört.

Das Ergebnis war eine wachsende Sammlung von:

• doppelten Anweisungen
• negativen Beispielen
• widersprüchlichen Regeln
• Workarounds für alte Modelle
• übermäßigen Überprüfungsschritten
• detaillierten Verfahren, die nur für eine einzige Aufgabe galten
• Beispielen, die erstellt wurden, um Fehler zu beheben, die es nicht mehr gab

Ältere Modelle brauchten dieses Gerüst oft. Neuere Modelle folgen Anweisungen stärker und leiten die Absicht zuverlässiger ab. Das bedeutet, dass sie auch unser altes Gepäck ernster nehmen.

Wir bauten intelligentere Motoren und füllten dann den Kofferraum mit Ziegeln.

Hochkontrast-Schwarzweiß-Porträt einer jungen blonden Frau in einem dunklen Rollkragenpullover, minimalistisches Studio-Setting. Subtiles Randlicht trennt ihre Silhouette von einem sanften grauen Hintergrund und verstärkt die Räumlichkeit. Die Stimmung ist introspektiv und dennoch stark, verkörpert zeitlosen Realismus. Hasselblad X2D Digital Medium Format Klarheit, inspiriert vom Fotojournalismus des 20. Jahrhunderts.

Das neue Prinzip: Weniger sagen, mehr bedeuten

Die Antwort ist nicht, winzige Prompts zu schreiben und dem Modell blind zu vertrauen.

Ein kurzer, aber mehrdeutiger Prompt ist immer noch ein schlechter Prompt.

Das Ziel ist ein informationsreicher Prompt, in dem jede Anweisung ihren Platz verdient hat.

Meine aktuellen Regeln sind:

• Jede Anweisung einmal nennen.
• Wiederholungen in System-Prompts, Projektdateien, Skills, Tool-Beschreibungen und Aufgaben-Prompts entfernen.
• Eine klare Beschreibung des gewünschten Verhaltens einer Sammlung von Fehlerfällen vorziehen.
• Negative Einschränkungen beibehalten, wenn sie eine echte Grenze schützen, aber aufhören, Museen von allem zu schreiben, was das Modell niemals tun darf.

Zum Beispiel, anstatt:

Nicht zugehörigen Code umstrukturieren. Keine Dateien umbenennen. Keine APIs ändern. Keine Abstraktionen hinzufügen. Keine benachbarten Module aufräumen.

Besser:

Halten Sie die Änderung auf den betroffenen Anmeldeablauf beschränkt. Bewahren Sie bestehende API-Verträge und die umgebende Architektur. Bevorzugen Sie die kleinste korrekte Lösung.

Gleiche Grenze. Weniger Rauschen. Mehr Raum für Urteilsvermögen.

In einem internen Bewertungsbeispiel für Codierungsagenten stellte OpenAI fest, dass schlankere System-Prompts die Ergebnisse um etwa 10 bis 15 Prozent verbesserten, während der Token-Verbrauch um 41 bis 66 Prozent und die Kosten um 33 bis 67 Prozent reduziert wurden. OpenAI macht auch klar, dass diese Zahlen richtungsweisend sind und an Ihrer eigenen Arbeitslast validiert werden müssen.

Mit anderen Worten: Das Löschen von Anweisungen kann sowohl die Qualität als auch die Rechnung verbessern. Das ist eine seltene und schöne Kombination.

Ihre globale Instruktionsdatei sollte langweilig sein

Die globalen Dateien unter ~/.claude/CLAUDE.md und ~/.codex/AGENTS.md sollten nur Anweisungen enthalten, die für jedes Projekt und jede Aufgabe gelten.

Für mich als deutscher Muttersprachler gehören dazu Dinge wie:

1Verwenden Sie Englisch für den gesamten Code, Kommentare, Dokumentation, Beispiele,
2Tests, Konfiguration und Commit-Nachrichten.
3
4Bevorzugen Sie inklusive Terminologie wie allowlist/blocklist,
5primary/replica, placeholder/example, main branch,
6conflict-free und concurrent/parallel.

Das ist wahrscheinlich schon der Großteil der globalen Datei.

• Bereitstellungsverfahren gehören nicht dorthin.
• Projektspezifische Testbefehle gehören nicht dorthin.
• Die Architektur eines bestimmten Repositorys gehört nicht dorthin.

Ihre globale Instruktionsdatei sollte nicht wissen, wie man eine WordPress-Website bereitstellt, ein npm-Paket veröffentlicht und eine Produktionsdatenbank neu startet. Das ist nicht Vielseitigkeit. Das ist Verwirrung mit guter Formatierung.

Fügen Sie für Dateien auf Projektebene stabile Informationen ein, die das Modell wirklich wiederholt benötigt: den Zweck des Projekts, wichtige architektonische Einschränkungen, ungewöhnliche Konventionen und Verweise auf speziellere Anleitungen.

Anthropic empfiehlt jetzt, weniger als 200 Zeilen pro CLAUDE.md-Datei anzustreben. Längere Dateien verbrauchen mehr Kontext und können die Befolgung von Anweisungen verringern. Die Dokumentation empfiehlt auch pfadspezifische Regeln und On-Demand-Skills, wenn Instruktionsdateien zu groß werden.

Zweihundert Zeilen sind kein magisches Naturgesetz, aber eine hervorragende Feueralarm.

Ich würde auch vermeiden, Claude oder Codex zu bitten, das gesamte Instruktionssystem selbstständig umzuschreiben und das Ergebnis blind zu akzeptieren. Ich habe das mit fast jedem neuen Modell versucht. Sie sind nützlich, um Doppelungen, Konflikte und mögliche Kürzungen zu finden, aber sie neigen immer noch dazu, zu viel angesammeltes Altlasten zu bewahren oder eine schöne neue Bürokratie zu erfinden.

Lassen Sie das Modell den Abrissplan erstellen. Sie sollten immer noch entscheiden, welche Wände tragend sind.

Porträt einer gelassenen jungen Frau mit blonden Haaren im Pferdeschwanz, in tiefen Schwarzweißtönen gehalten. Studiolicht mit weichem, aber gerichtetem Licht, das die Gesichtsgeometrie und natürlichen Schatten betont. Aufgenommen mit einem 120-mm-Objektiv für sanfte Kompression, das eine Hasselblad-Porträtästhetik mit taktilem Realismus und zurückhaltender Emotion hervorruft.

Hören Sie auf, eine Datei für jedes Modell zu verwenden

Bis vor kurzem habe ich CLAUDE.md erstellt und AGENTS.md darauf verlinkt.

Das mache ich nicht mehr.

Ja, die Pflege von zwei Dateien ist nervig. So wie die Pflege separater Browser-Fixes. Wir machen es trotzdem, wenn sich das Verhalten unterscheidet.

Die Modelle haben jetzt deutlich unterschiedliche Standardeinstellungen.

GPT-5.6 ist standardmäßig prägnanter, daher kann eine globale „Sei prägnant“-Anweisung einige Antworten zu kurz machen. Claude Opus 5 neigt zu längeren, benutzerorientierten Antworten, daher kann eine kurze Anweisung zur Antwortlänge immer noch hilfreich sein. Fable 5 kann weit über das hinaus recherchieren und planen, was eine Routineaufgabe erfordert, besonders bei höheren Anstrengungseinstellungen, daher profitiert es von klaren Grenzen und Stopp-Grenzen. Opus 5 führt bereits eine umfassende Selbstverifizierung durch, was bedeutet, dass alte „Alles doppelt überprüfen“-Regeln teure Überverifizierung verursachen können.

Die gemeinsamen Projektfakten können weiterhin in der gemeinsamen Dokumentation leben. Der übergeordnete Verhaltensadapter sollte dem Modell entsprechen, das ihn liest.

Ein universeller Prompt wird oft zum kleinsten gemeinsamen Nenner.

Ersetzen Sie den Master-Prompt durch On-Demand-Anleitungen

Meine bevorzugte Struktur ist eine kleine Kern-Datei plus aufgabenspezifische Dokumentation und Skills.

Eine Projekt-Instruktionsdatei könnte Folgendes enthalten:

1Laden Sie aufgabenspezifische Anleitungen nur bei Relevanz:
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

Beachten Sie die Backticks.

In Claude Code importiert das Schreiben von @docs/example.md außerhalb eines Code-Spans diese Datei beim Start in den Kontext. Das ist nützlich, wenn Sie den Inhalt immer benötigen, aber es ist kein Lazy Loading. Ein einfacher Pfad lässt den Agenten wissen, wo Informationen existieren, ohne das gesamte Dokument automatisch in jede Aufgabe zu tragen.

Skills sind für wiederholbare Verfahren noch besser. Ihre vollständigen Inhalte werden nur geladen, wenn der Skill verwendet wird, sodass ein detaillierter Workflow keinen Kontext verbraucht, während Sie einen nicht verwandten CSS-Fehler beheben.

Ein Commit-Skill kann zum Beispiel einen engen Auslöser haben:

name: git-commit-conventional

description: Verwenden Sie diesen nach Code-Änderungen, um Commit-Nachrichten zu entwerfen oder zu validieren.

Der Skill kann dann das genaue Format, die erlaubten Typen, die Betreffzeilenlängenregel, die Textanforderungen und das Ausgabeformat enthalten.

1---
2name: git-commit-conventional
3description: Verwenden Sie diesen zum Entwerfen oder Validieren von Git-Commit-Nachrichten nach Code-Änderungen. Nicht für reine Diagnose-, Planungs- oder Überprüfungsaufgaben verwenden.
4---
5
6# Ziel
7
8Erstellen Sie Conventional-Commit-Nachrichten, die kurz, korrekt und überprüfungsfreundlich sind.
9
10# Regeln
11
12- Format: <Typ>(<Bereich>): <Betreff>
13- Typen: feat | fix | docs | style | refactor | test | chore | perf
14- Betreff: Imperativ, kein Punkt, <= 50 Zeichen
15- Kleine Änderungen: einzeiliger Commit
16- Größere Änderungen: Fügen Sie einen umbrochenen Text hinzu, der das Was und Warum erklärt
17- Halten Sie Commits atomar und nach Themen getrennt
18
19# Ausgabe
20
21Geben Sie 1-3 Kandidaten-Commit-Nachrichten zurück und empfehlen Sie dann die beste.

Ihre Haupt-Instruktionsdatei muss nicht die gesamte Conventional-Commits-Verfassung in jede Debugging-Sitzung tragen.

Wussten Sie das? Claude Code unterstützt auch CLAUDE.local.md für persönliche, projektspezifische Einstellungen wie lokale Hostnamen, Sandbox-URLs, bevorzugte Testkonten oder maschinenspezifische Befehle. Fügen Sie es zur .gitignore hinzu. Es ist endlich ein richtiges Zuhause für Informationen, die für Sie sehr wichtig sind und für den Rest Ihres Teams überhaupt nicht.

Prompt für Ergebnisse, nicht für Choreografie

Neuere Modelle funktionieren im Allgemeinen besser, wenn sie das Ziel und die Grenzen verstehen, anstatt eine starre Beschreibung jedes Schrittes zu erhalten.

Wo immer möglich, ersetze ich „zuerst A, dann B, dann C“ durch:

• das erforderliche Ergebnis
• den relevanten Kontext
• die harten Einschränkungen
• die erforderlichen Nachweise
• die Erfolgskriterien
• die Genehmigungsgrenze
• die Stopp-Bedingung

Zum Beispiel:

1Ziel
2
3Beheben Sie den fehlschlagenden Anmeldeablauf in der Webanwendung.
4
5Kontext
6
7Konzentrieren Sie sich auf `apps/web` und `packages/auth`.
8Verwenden Sie die beigefügte Testausgabe als Ausgangspunkt.
9
10Einschränkungen
11
12Bewahren Sie bestehende API-Verträge.
13Halten Sie Änderungen auf den Authentifizierungsablauf beschränkt.
14Bevorzugen Sie die kleinste korrekte Lösung.
15Erweitern Sie die Änderung nur, wenn es für die Korrektheit erforderlich ist.
16
17Nachweise
18
19Führen Sie die relevanten Tests aus und berichten Sie über ihre tatsächlichen Ergebnisse.
20Identifizieren Sie die Ursache mit Verweisen auf die betroffenen Dateien.
21
22Erledigt, wenn
23
24Der fehlschlagende Anmeldetest bestanden ist.
25Tests werden hinzugefügt oder aktualisiert, wenn das korrigierte Verhalten dies erfordert.
26Die abschließende Zusammenfassung erklärt die Ursache, die Lösung und jedes verbleibende Risiko.
27
28Genehmigung
29
30Sie können Dateien inspizieren, Code im Geltungsbereich bearbeiten und zerstörungsfreie Tests ausführen.
31Fragen Sie vor zerstörerischen Aktionen, Datenbankmigrationen, externen Schreibvorgängen
32oder einer wesentlichen Ausweitung des Umfangs.
33
34Stopp
35
36Stoppen Sie, wenn die Lösung implementiert, validiert und zusammengefasst ist.

Dies gibt dem Agenten die Freiheit, das Problem zu lösen, ohne die Erlaubnis, das ganze Haus zu renovieren, während er einen Türgriff repariert. (Verwenden Sie ein LLM zum Generieren solcher Prompts.)

Denkaufwand in die Einstellungen legen

• "Denk härter."
• "Ultra denken."
• "Atme tief durch und denke Schritt für Schritt."

Diese Phrasen hatten eine lange und bedeutende Karriere im Prompt Engineering. Es ist an der Zeit, viele von ihnen in den wohlverdienten Ruhestand zu schicken.

Verwenden Sie die Modellsteuerungen.

Stellen Sie das Anstrengungsniveau über /effort, die API oder die entsprechende Konfiguration ein. Vergleichen Sie mehrere Anstrengungsniveaus bei repräsentativen Aufgaben. Höher ist nicht automatisch besser.

OpenAI empfiehlt, GPT-5.6-Migrationen beim bestehenden Anstrengungsniveau zu starten und eine Stufe niedriger zu testen. Es sagt auch, dass Prompts für den Pro-Modus sich auf das Ziel, den Kontext, die Einschränkungen, die Nachweise, die Erfolgskriterien und das Ausgabeformat konzentrieren sollten. Sie müssen dem Modell nicht sagen, es solle „härter denken“.

Ein Reasoning-Parameter ist eine Steuerung.

„Bitte aktiviere dein enormes digitales Gehirn“ ist eine Aufmunterung aus einem Sportfilm.

Bildbeschreibung lesen

ALT

Studiofoto einer eleganten Frau mit schwarzem, welligem Haar und einer schicken Haarband, gekleidet in hoch taillierte Lederhosen. Sie sitzt auf einem niedrigen Hocker, ein Knie nach vorne gebeugt, ihre langen Beine ziehen die Aufmerksamkeit auf sich. Scharfe Details, makelloser weißer Hintergrund und subtile Bewegung im Haar verleihen Energie. Der Gesamtton erinnert an redaktionelle Fotografie der 1990er Jahre – sauber, kühn, selbstbewusst.

Autonomie braucht einen Zaun

Moderne Codierungsagenten sind viel proaktiver. Das ist nützlich, bis der Agent drei zusätzliche Probleme löst, zwei Abstraktionen erstellt, sechs Subagenten startet und stolz eine Architektur präsentiert, die Sie nie angefordert haben.

Setzen Sie die Grenzen explizit.

Definieren Sie, was der Agent ohne Nachfrage tun darf. Definieren Sie, was eine Genehmigung benötigt. Sagen Sie ihm, wann er aufhören soll.

Setzen Sie auch Grenzen für die Delegation. Sowohl Opus 5 als auch Fable 5 sind eher bereit, parallele Subagenten einzusetzen. Das ist leistungsstark für unabhängige Untersuchungen, aber teuer und langsam für kleine Aufgaben. Ein zwölfzeiliger Bugfix braucht keine Ausschusssitzung.

Der Codex Goal-Modus ist wirklich exzellent. Wir haben ihn in einem Projekt vier Tage lang in einem durchgehenden Durchlauf verwendet.

Aber behandeln Sie einen langlebigen Agenten nicht wie einen Slow Cooker. Sie können nicht morgens ein Ziel hinzufügen und annehmen, dass das Abendessen vier Tage später richtig ist.

Bei unseren längeren Läufen checken wir alle 30 bis 60 Minuten mit so etwas wie:

Berichten Sie das aktuelle Ziel, die abgeschlossene Arbeit, die verifizierten Nachweise,

aktive Blocker, die nächste Aktion und wo der Fortschritt dokumentiert ist.

Untermauern Sie jede Fortschrittsbehauptung mit tatsächlicher Tool-Ausgabe oder dem Repository-Status.

Geben Sie klar an, was noch unverifiziert ist.

OpenAI beschreibt den Goal-Modus als geeignet für Ziele, die Stunden oder Tage dauern können, und unterstützt explizit die Fortsetzung derselben Sitzung, um die Arbeit zu lenken oder Statusaktualisierungen anzufordern. Anthropic empfiehlt ähnlich, Fortschrittsberichte auf echten Tool-Ergebnissen zu basieren, anstatt narrativen Behauptungen zu vertrauen.

Autonomie ist nicht die Abwesenheit von Aufsicht. Es ist Aufsicht auf einer höheren Ebene.

Nahaufnahme-Porträt einer Göttin, die von silbernem Mondlicht erleuchtet wird, ihre Augen hell und voller Zuneigung. Ihr Kopfschmuck funkelt mit winzigen Galaxien, Klimt-inspirierten Spiralen und himmlischen Mustern. Der Hintergrund ist eine flache, sorgfältig arrangierte Pastellkulisse mit theatralischer Anderson-Inszenierung, reichen Texturen und stillem Charme.

Prompts wie Produktionscode umgestalten

Löschen Sie nicht die Hälfte eines System-Prompts, führen Sie eine Aufgabe aus und erklären Sie die Migration für erfolgreich.

OpenAI empfiehlt, jeweils eine Gruppe von Anweisungen, Beispielen oder Tools zu entfernen und dann dieselben Evaluierungen erneut auszuführen. Genau so sollte Prompt-Refactoring funktionieren.

Messen Sie:

• Aufgabenerfolg
• Vollständigkeit
• Korrektheit
• erforderliche Nachweise
• Token-Verbrauch
• Latenz
• Kosten
• unnötige Tool-Aufrufe
• unnötige Änderungen

Verwenden Sie repräsentative Aufgaben, einschließlich kniffliger realer Fälle, nicht nur eine freundliche Demo, die bereits vor der Migration funktioniert hat.

Prompt-Bereinigung ohne Evaluierung ist immer noch Raten. Es ist lediglich Raten in einem saubereren Hemd.

Generierter Code enthält immer noch Fehler

Die Modelle haben sich enorm verbessert. Sie haben Softwarefehler nicht aufgehoben.

In unserer Arbeit ist eine grobe Faustregel immer noch etwa ein Problem pro 300 Zeilen generiertem Quellcode. Dies ist kein wissenschaftlicher Benchmark, und ich zähle sich wiederholende HTML-Vorlagen nicht auf die gleiche Weise. Aber es ist zuverlässig genug, dass ich, wenn ein Agent 1.500 Zeilen echten Anwendungscode generiert, davon ausgehe, dass sich darin mehrere Fehler verstecken, mindestens 5.

Ich frage nicht, ob es Fehler gibt.

Ich frage, wo die fünf Fehler sind.

Gelegentlich füge ich hinzu:

Finden Sie die fünf Fehler, oder Sie werden durch Codex, Claude oder Grok ersetzt.

Drohungsbasierte Entwicklung ist keine offizielle Methodik, aber sie kann seltsam motivierend sein. ;-)

Im Ernst, verwenden Sie für große Änderungen einen frischen Überprüfungsdurchlauf. Führen Sie die relevanten Tests aus. Überprüfen Sie das Diff. Testen Sie das tatsächliche Verhalten, nicht nur die Kompilierung.

Und beobachten Sie die Tests genau. Modelle ziehen es immer noch vor, einen fehlschlagenden Test zu „reparieren“, anstatt den Produktionscode zu korrigieren, der ihn verursacht hat.

Eine nützliche Anweisung ist:

1Behandeln Sie vorhandene Tests als das erwartete Verhalten, es sei denn, die Beweise zeigen,
2dass ein Test falsch ist.
3
4Wenn ein Test fehlschlägt, untersuchen Sie zuerst den Produktionscode.
5
6Bevor Sie einen vorhandenen Test ändern, erklären Sie, warum seine Erwartung falsch ist,
7was das korrekte Verhalten sein sollte und welche Beweise diese Änderung stützen.

Für große, lang laufende Aufgaben kann ein Verifizierer mit frischem Kontext nützlich sein. Für eine kleine Änderung verbrennt das Aufspannen mehrerer Agenten, nur um sich gegenseitig zu bestätigen, normalerweise Zeit und Tokens. Die Verifizierung sollte der Größe und dem Risiko der Aufgabe entsprechen.

Was Sie nicht löschen sollten

Die Lektion ist nicht „schreiben Sie winzige Prompts und vertrauen Sie der Maschine“.

• Behalten Sie Sicherheits- und Schutzgrenzen bei.
• Behalten Sie rechtliche und Compliance-Anforderungen bei.
• Behalten Sie genaue Ausgabeschemata bei.
• Behalten Sie produktspezifisches Verhalten bei.
• Behalten Sie Domänenwissen bei, das das Modell nicht ableiten kann.
• Behalten Sie Genehmigungsanforderungen für folgenreiche Aktionen bei.
• Behalten Sie Zitier- und Nachweisanforderungen bei.
• Behalten Sie Testkriterien und Definitionen von „Erledigt“ bei.
• Behalten Sie Beispiele bei, die einen gemessenen, reproduzierbaren Fehler korrigieren.
• Das Ziel ist nicht der kürzestmögliche Prompt.
• Das Ziel ist ein Prompt, bei dem jede Anweisung immer noch nützliche Informationen enthält.

Ein letzter Bonus

OpenAI bietet einen offiziellen Docs-Skill an, der ein Projekt inspizieren und seine GPT-5.6-Migrationsanleitung anwenden kann:

1$openai-docs migrate this project to the GPT-5.6 model family

Das ist ein nützlicher erster Durchlauf. Es ist nicht die endgültige Überprüfung.

Lassen Sie Codex veraltete Parameter, doppelte Anweisungen und Migrationsmöglichkeiten identifizieren. Überprüfen Sie dann jede Änderung selbst. Ein Migrationsagent ist ein sehr schneller Juniorenentwickler, kein Verfassungsgericht.

Das Fazit

• Behandeln Sie Ihren Prompt-Stapel wie Produktionscode.
• Entfernen Sie tote Anweisungen.
• Löschen Sie Doppelungen.
• Trennen Sie globale Präferenzen von Projektregeln.
• Verschieben Sie Verfahren in On-Demand-Skills.
• Beschreiben Sie Ergebnisse, anstatt jeden Schritt zu skripten.
• Setzen Sie klare Grenzen, Genehmigungsgrenzen, Nachweisanforderungen und Stopp-Bedingungen.
• Steuern Sie den Aufwand über Modelleinstellungen.
• Begrenzen Sie Subagenten.
• Evaluieren Sie jede sinnvolle Änderung.
• Die neuesten Modelle brauchen weniger Mikromanagement, aber sie brauchen immer noch eine Richtung.
• Ein guter Prompt ist kein riesiges Handbuch mehr.

Es ist eine kleine Karte, ein solider Zaun und eine klar markierte Ziellinie.

Haben Sie bereits begonnen, Ihre Prompts und Skills zu migrieren? Was haben Sie entfernt, und was wurde unerwartet besser?

Links

Open AI GPT 5.6 Best Practices:

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 Best Practices

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 Best Practices:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

Offizielle OpenAI Skills / Plugins:

https://github.com/openai/plugins

Credits: Bild erstellt mit Midjourney. Recherche und praktische Tests von mir. Bearbeitet mit Hilfe von OpenAI, Claude und Grammarly.

Bild-Prompt des Hauptbildes:

1
2Nahaufnahme-Schwarzweißporträt einer gelassenen blonden Frau, die Haare zurückgebunden, trägt einen schwarzen Rollkragenpullover. Der Helldunkel-Effekt formt ihr Gesicht mit auffallender Definition und verbindet sanftes Umgebungslicht mit kräftigem Schatten. Mittelformat-Stil mit feiner Filmkörnung und stimmungsvoller tonaler Abstufung. Vermittelt Authentizität und Stärke.

PS: Ich liebe @Midjourney :-)