Eric Provencher von OpenAI hat aufgeschrieben, was beim Wechsel auf GPT-6 Astra aus den eigenen Projekten fliegen sollte. Der Text dreht sich um Codex, aber wer mit Claude Code arbeitet, liest hier über seine eigene CLAUDE.md.
Die Grundthese in einem Satz: Anweisungen, die sich über Monate angesammelt haben, kosten Kontext oder bringen das Modell dazu, zu früh aufzuhören.
Skills: kürzer ist präziser
Skills sind Prompts als Markdown-Dateien, oft mit Ressourcen und Skripten dabei. Name und Beschreibung landen im Kontext, damit das Modell weiß, wann es zugreifen soll. Wer viele davon einsammelt, bekommt ein Problem: Codex kürzt die Beschreibungen, um sie unterzubringen. Das Modell sieht dann von jeder Beschreibung weniger und wählt schlechter.
Provencher zeigt das an einem Beispiel. Schlecht:
Postgres-Schema-Migrationen erstellen und prüfen. Nutzen bei Datenbanken, Queries, Modellen oder Persistenz.
Besser:
Postgres-Schema-Migrationen erstellen und prüfen. Nutzen beim Anlegen oder Ändern einer Migration oder beim Prüfen ihres Rollouts.
Die erste Variante feuert bei allem, was entfernt nach Datenbank riecht. Der zweite Punkt ist progressive Disclosure: Bei Skills mit mehreren Workflows soll das Hauptdokument nur ein schlanker Wegweiser sein, der auf Unterdokumente und Skripte zeigt. Jede Datei, die das Modell liest, frisst Kontext und rückt die Kompaktierung näher.
Und drittens: Viele Skills sind als Schritt-für-Schritt-Rezept geschrieben. Neuere Modelle kommen mit Mehrdeutigkeit besser klar, deshalb kann genau diese Detailtreue jetzt schaden. Heikel wird es bei Repository-Skills, weil sie auch die Agenten anderer Leute steuern. Was Sol oder Luna hilft, engt Astra womöglich schon ein.
AGENTS.md: Pflichtlektüre streichen
Die Regeln in AGENTS.md gelten immer, wenn das Modell im Repository arbeitet. Provencher rät, jede einzelne regelmäßig zu hinterfragen. Ein Stapel Dokumente vor jeder Änderung ist für einen Tippfehler übertrieben – Astra findet selbst heraus, was es lesen muss.
Statt „lies vor jeder Änderung architecture.md, database.md und deployment.md” also lieber: architecture.md für Service-Grenzen, database.md für Schema-Änderungen, deployment.md vor einem Deployment. Und die Dokumente aktuell halten, sonst bringt der Verweis nichts.
Ältere Modelle brauchten einen Schubs, um Tests laufen zu lassen. Astra macht das von allein, dieselbe Anweisung führt jetzt zu unnötigen Testläufen. Umgekehrt hilft eine ausdrückliche Erlaubnis gegen Dauerrückfragen – etwa für eine lokale Testsuite mit Wegwerfdaten und ohne Produktionszugriff: laufen lassen, Fehler beheben, betroffene Tests erneut ausführen, ohne bei jedem Schritt zu fragen.
Grenzen: zu streng ist auch falsch
Wer früheren Modellen mit harter Sprache das eigenmächtige Handeln ausgetrieben hat, sollte diese Sätze beim Wechsel noch mal ansehen. OpenAI nennt Astra sein am besten ausgerichtetes Modell und schreibt ihm besseres Urteilsvermögen zu – es nimmt alte Verbote unter Umständen so wörtlich, dass es stehen bleibt, wo du gern weitergearbeitet hättest.
Dazu passt der letzte Punkt: Astra hört früher auf als GPT-5.6 Sol. Es liefert eine erste Implementierung und kommt zur Abnahme zurück, obwohl noch Arbeit offen ist. Provencher rät, vorher zu definieren, was „fertig” heißt. Wenn Ausführen, Ergebnis prüfen und Fehler beheben dazugehören, muss das in den Auftrag.
Warum das hier steht
Skills, eine Projektdatei mit Dauerregeln, Berechtigungen, Kompaktierung – das ist dieselbe Mechanik, die auch Claude Code antreibt. Und dieselbe Sammelwut: Wer seit einem Jahr CLAUDE.md pflegt, hat dort Regeln stehen, die gegen Probleme von damals geschrieben wurden.
Provenchers Schlussvorschlag lässt sich direkt übernehmen: Lass das Modell die eigene Konfiguration prüfen, statt jede Zeile von Hand durchzugehen. Das ist bequem und immerhin überprüfbar – der Vorschlag kommt zurück, bevor etwas geändert wird.
Quellen: OpenAI Developers: Rethinking skills and prompts for GPT-6 Astra, The Decoder