OpenAI: Alte Skills bremsen GPT-6 Astra aus

Wer seit einem Jahr mit Coding-Agenten arbeitet, hat Regeldateien voller Anweisungen, die irgendwann mal einen Fehler verhindern sollten. OpenAI sagt jetzt: Mit GPT-6 Astra wird ein Teil davon zum Hindernis. Eric Provencher hat am 11.09.2026 im Entwicklerblog aufgeschrieben, was an Skills, AGENTS.md und Aufgabenprompts raus kann und was anders formuliert werden sollte.

Die Empfehlungen sind konkret genug, dass man sie heute Nachmittag im eigenen Repo umsetzen kann. Ein Punkt davon verdient allerdings Widerspruch.

Kürzere Skill-Beschreibungen

Jeder Skill bringt Name und Beschreibung mit, die dauerhaft im Kontext des Modells stehen, damit es weiß, wann es ihn braucht. Laut OpenAI sind viele Beschreibungen viel zu lang. Bei vielen Skills kürzt Codex sie sogar selbst, damit alles hineinpasst, und das Modell sieht dann weniger von jeder Beschreibung. Dazu kommen Beschreibungen, die sich widersprechen oder den Einsatz übertreiben. Dann lädt das Modell Anleitungen, die bei der aktuellen Aufgabe nicht helfen.

Das Beispiel aus dem Beitrag zeigt den Unterschied an einer Zeile:

Schlecht: Create and validate Postgres schema migrations. Use when working with databases, queries, models, or persistence.
Gut:      Create and validate Postgres schema migrations. Use when adding or changing a migration, or reviewing its rollout.

Die erste Fassung zieht den Skill bei jeder Datenbankarbeit heran, die zweite nur bei Migrationen. Weitere Punkte:

• Progressive Disclosure: Hat ein Skill mehrere Abläufe, soll die Hauptdatei nur ein knapper Wegweiser zu Unterdokumenten und Skripten sein. Alles, was gelesen wird, kostet Kontext und rückt die Verdichtung näher.
• Keine Kochrezepte: Viele Skills sind als detaillierte Schrittfolgen geschrieben. Weil Modelle mit Mehrdeutigkeit inzwischen besser umgehen, schaden allzu genaue Vorgaben laut OpenAI mittlerweile dort, wo sie früher geholfen haben.
• Andere Modelle mitdenken: Skills im Repository nutzen auch die Agenten von Kolleginnen und Kollegen, womöglich mit einem anderen Modell. Was GPT-5.6 Sol hilft, kann Astra zu eng führen.

Die Anleitung im Skill $skill-creator, mit dem viele ihre Skills anlegen, hat OpenAI nach eigenen Angaben entsprechend überarbeitet.

Keine Lesepflicht vor jeder Änderung

AGENTS.md gilt bei jeder Arbeit im Repository. Deshalb soll man jede Zeile regelmäßig fragen, ob sie noch gebraucht wird. Das Paradebeispiel ist die Lesepflicht vor jeder Änderung:

Für einen Tippfehler drei Dokumente zu lesen, verbrennt Kontext und bremst die Arbeit. Die Dokumente bleiben nützlich, der Verweis hängt nur an der passenden Situation. Und sie müssen aktuell sein, betont der Beitrag.

Zweiter Punkt: Frühere Modelle musste man ermuntern, Tests laufen zu lassen. Astra tut das laut OpenAI von selbst, alte Anweisungen dazu führen zu unnötigen Testläufen. Gleichzeitig sei Astra zögerlicher, wie weit es eine Aufgabe treiben soll. Für Abläufe, die ihr als sicher kennt, schlägt OpenAI eine ausdrückliche Erlaubnis vor:

The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.

Die Erlaubnis hat eine Begründung eingebaut: wegwerfbare Testdaten, kein Produktionszugriff. Genau das macht sie brauchbar.

Im Prompt sagen, wann es fertig ist

Wer von GPT-5.6 Sol kommt, kennt ein Modell, das lange am Stück durcharbeitet. Astra liefert laut Beitrag eher eine erste Umsetzung ab und fragt nach Review, obwohl noch Arbeit offen ist. Der Rat: vorher festlegen, was "fertig" heißt. Gehört dazu, die Umsetzung zum Laufen zu bringen, das Ergebnis anzusehen und Fehler zu beheben, muss das im Auftrag stehen. Eine Pflicht, nach der ersten Umsetzung zur Freigabe anzuhalten, zieht das Modell zu einem früheren Haltepunkt. Man solle prüfen, ob man diese Entscheidung wirklich selbst treffen muss.

Gilt das auch für Claude?

Im Kern ja, und neu ist es nicht. Anthropics Leitfaden für Skills sagt weitgehend dasselbe: Beschreibungen sollen klar sagen, was ein Skill tut und wann er gebraucht wird, SKILL.md soll als Inhaltsverzeichnis auf Details verweisen und unter 500 Zeilen bleiben. Die Grundannahme dort lautet "Claude is already very smart". Auch den Mehrmodell-Punkt kennt der Leitfaden: Skills sollen mit Haiku, Sonnet und Opus getestet werden, weil ein großes Modell weniger Erklärung braucht als ein kleines.

Für CLAUDE.md empfiehlt Anthropic in der Claude-Code-Doku unter 200 Zeilen pro Datei und Regeln, die per paths nur bei passenden Dateien geladen werden. Die Best Practices geben eine Prüffrage für jede Zeile mit: "Would removing this cause Claude to make mistakes?" Wenn nicht, raus damit. Claude Code liest übrigens CLAUDE.md und nicht AGENTS.md. Wer beides pflegt, kann die AGENTS.md in die CLAUDE.md importieren.

Wir haben das Prinzip in Harness Engineering als "Karte statt Handbuch" beschrieben: kurze Regeldatei als Wegweiser, das Wissen in Dokumenten und Skills dahinter. OpenAIs neuer Beitrag ist die modellspezifische Fortsetzung davon.

Was sich nicht eins zu eins überträgt, sind die Aussagen zum Verhalten: dass Astra von selbst testet, zögerlicher stoppt und alte Verbote zu ernst nimmt. Das beschreibt OpenAI für sein eigenes Modell, und es ist eine Herstellerbeobachtung ohne veröffentlichte Messung. Ob eure Anweisungen bei Claude oder einem anderen Modell überflüssig sind, findet ihr nur heraus, indem ihr eine Zeile streicht und schaut, ob sich das Verhalten ändert.

Weniger Freigaben, aber wo?

Heikel wird der Abschnitt zu Entscheidungsgrenzen. Wer früheren Modellen nach ungefragten Alleingängen strenge Rückfragepflichten verordnet hat, soll sie für Astra lockern. Die Begründung:

GPT-6 Astra, as our most aligned model, has much better judgment and will not perform tasks unless it knows it is safe

Das ist eine Selbsteinschätzung des Herstellers, und sie fällt in eine Zeit, in der das Thema Agenten ohne Grenzen nicht gerade ruhig ist. OpenAI selbst hat Astra Anfang September als erstes Modell in die höchste Cyber-Risikostufe eingeordnet, siehe unsere News dazu. Über Agenten-Vorfälle bei Anthropic und den Agentenschwarm, der Amodei zu seinem Tempo-Essay bewogen hat, haben wir in den letzten Wochen mehrfach berichtet. Welches Modell hinter dem Schwarm steckte, ist nicht belegt, Astra wird dort nicht beschuldigt. Aber gutes Urteilsvermögen ist keine Eigenschaft, auf die man eine Produktionsdatenbank verwetten sollte.

Der Widerspruch löst sich, wenn man zwei Arten von Freigaben trennt:

Anthropic formuliert das in der Claude-Code-Doku ausdrücklich: CLAUDE.md ist Kontext, keine erzwungene Konfiguration. Was unabhängig vom Modell blockiert werden soll, gehört in einen Hook oder in die Berechtigungen. Wie solche Prüfungen aussehen, die niemand vergessen kann, steht in Quality-Gates gegen KI-Fehler. So gebaut, könnt ihr die Prosa ausdünnen, ohne irgendeinem Modell mehr zu vertrauen als nötig.

Was das für euch heißt

Einordnung

Der Beitrag ist nüchterner und nützlicher als die meisten Prompting-Tipps der Hersteller. Das meiste darin gilt modellübergreifend und deckt sich mit dem, was Anthropic für Claude empfiehlt: weniger Dauerkontext, Verweise an Situationen, Skills als Wegweiser. Den Satz zur Entscheidungsgrenze solltet ihr nicht ungeprüft übernehmen. Freigabeschritte, die nur Zeit kosten, dürfen weg. Grenzen, die Schaden verhindern, gehören nicht in eine Textdatei, die das Modell auslegen kann, und schon gar nicht in das Vertrauen auf ein Urteilsvermögen, das der Hersteller seinem eigenen Modell bescheinigt.