For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation
11. Sept. 2026 Codex

Skills und Prompts für GPT-6 Astra neu denken

Überarbeite Skill-Beschreibungen, AGENTS.md und Aufgaben-Prompts, damit der Kontext nicht unnötig anwächst.

Verfasst von: Eric Provencher

Skills und Prompts für GPT-6 Astra neu denken

Programmieragenten haben große Fortschritte gemacht, und bewährte Methoden ändern sich schnell. Leistungsfähigere Modelle erledigen heute vieles ohne die engmaschige Anleitung und Hilfskonstruktionen, die früher nötig waren.

Wenn du im vergangenen Jahr Agenten wie Codex für deine Projekte eingesetzt hast, hast du wahrscheinlich viele Anweisungen gesammelt, um die Modelle zu guten Ergebnissen zu führen. Es hat sich bei jeder neuen Version gelohnt, die zugrunde liegenden Annahmen zu hinterfragen. Mit GPT-6 Astra ist das wichtiger denn je.

Diese Anweisungen können unterschiedliche Formen annehmen: Skills, AGENTS.md und deine Aufgaben-Prompts beeinflussen allesamt, wie das Modell seine Arbeit erledigt.

Bessere Skills

Eine mögliche Form dieser Anweisungen sind Skills. Im Kern sind das Prompts, die als Markdown-Dateien gespeichert und zusammen mit Ressourcen und Skripten bereitgestellt werden können. Am nützlichsten sind sie in der Regel als Anleitung für einen bestimmten Ablauf oder für die Nutzung bestimmter Apps.

Inzwischen gehört es für viele dazu, zahlreiche Skills in ihre Projekte aufzunehmen. Jeder Skill hat einen Namen und eine Beschreibung, die in den Kontext des Modells geladen werden, damit es weiß, wann es ihn verwenden soll. Viele Beschreibungen sind jedoch viel zu lang. Wenn du zu viele Skills hinzufügst, beginnt Codex, ihre Beschreibungen zu kürzen, damit sie noch hineinpassen. Das Modell sieht dann weniger von jeder Beschreibung und kann schwerer entscheiden, welchen Skill es auswählen soll.

Hinzu kommt, dass sich Beschreibungen häufig widersprechen oder zu nachdrücklich zum Einsatz von Skills auffordern. Dadurch lädt das Modell Anweisungen, die bei der eigentlichen Aufgabe nicht helfen.

Skills werden häufig mithilfe des Skills $skill-creator erstellt. Wir haben seine Anleitung kürzlich aktualisiert, um viele der Probleme zu verringern, die wir in der Praxis beobachtet haben.

Erstens sollten Skill-Beschreibungen so kurz wie möglich sein und zugleich klar benennen, wann das Modell den jeweiligen Skill verwenden soll:

Benenne klar, wann der Skill gilt
Schlecht

Erstelle und validiere Postgres-Schemamigrationen. Verwende diesen Skill bei der Arbeit mit Datenbanken, Abfragen, Modellen oder Persistenz.

Gut

Erstelle und validiere Postgres-Schemamigrationen. Verwende diesen Skill, wenn du eine Migration hinzufügst oder änderst oder ihren Rollout überprüfst.

Die schlechte Skill-Beschreibung kann das Modell hier dazu bringen, den Skill bei allem zu verwenden, was mit einer Datenbank zu tun hat, statt nur dann, wenn es eine Migration bearbeiten muss.

Zweitens zeichnet sich ein nützlicher Skill dadurch aus, dass er Informationen schrittweise bereitstellt. Einen Skill zu lesen, belegt Platz im Kontext und bringt die nächste Compaction (Kontextverdichtung) näher. Außerdem gelangen dabei möglicherweise Anweisungen in den Kontext, die für die Aufgabe nicht relevant sind. Bei Skills mit mehreren Arbeitsabläufen sollte das Hauptdokument lediglich knapp auf die passenden weiterführenden Dokumente und Skripte verweisen. Gib dem Modell genug Orientierung, damit es weiß, wo es nachsehen soll, ohne es zum Lesen von Dingen zu zwingen, die gerade keine Rolle spielen.

Drittens wurden viele Skills als ausführliche Ablaufpläne oder Rezepte geschrieben. Modelle verstehen Nuancen und Mehrdeutigkeit inzwischen deutlich besser. Übermäßig genaue Vorgaben können deshalb heute Ergebnisse beeinträchtigen, obwohl sie früher hilfreich waren.

Skills im Repository leiten auch die Agenten anderer Mitwirkender an, die möglicherweise andere Modelle verwenden. Anweisungen, die Sol oder Luna helfen, können GPT-6 Astra zu stark einschränken. Überlege deshalb, welche Modelle die Anweisungen nutzen werden, die du hinterlässt.

AGENTS.md aktuell halten

Da AGENTS.md immer gilt, wenn das Modell in deinem Repository arbeitet, solltest du jede Anweisung regelmäßig überprüfen und dich fragen, ob sie noch nötig ist.

Vor jeder Änderung die Lektüre zahlreicher Dokumente oder eine vollständige Bestandsaufnahme des Repositorys zu verlangen, ist für die Korrektur eines Tippfehlers übertrieben. GPT-6 Astra kann selbst herausfinden, was es lesen muss, ohne vor jeder Änderung zur Durchsicht des gesamten Projekts aufgefordert zu werden.

Lies, was für die Aufgabe nötig ist
Schlecht

Lies vor jeder Änderung architecture.md, database.md und deployment.md.

Gut

Nutze architecture.md für die Abgrenzung von Diensten, database.md für Schemaänderungen und deployment.md, wenn du ein Deployment vorbereitest.

Das Modell vor jeder Änderung zum Lesen von Dateien aufzufordern, verbraucht reichlich Kontext und bremst die Arbeit. Auf Dokumentation zu verweisen, kann trotzdem hilfreich sein, solange der Verweis zur jeweiligen Aufgabe passt. Halte auch deine Dokumentation aktuell!

Frühere Modelle brauchten einen Anstoß, um Tests auszuführen und ihre Arbeit zu überprüfen. GPT-6 Astra tut das von sich aus, sodass dieselben Anweisungen zu unnötigen Tests führen können.

GPT-6 Astra arbeitet gründlich, kann aber zögerlicher sein, wenn es darum geht, wie weit es eine Aufgabe ausführen soll. Manchmal braucht es einen kleinen Anstoß, um weiterzumachen. In AGENTS.md kannst du ihm einen bestimmten Ablauf erlauben, von dem du weißt, dass er sicher ist, etwa das Ausführen einer lokalen Testsuite:

Die lokalen Tests verwenden Test-Fixtures, die anschließend verworfen werden, und haben keinen Zugriff auf die Produktivumgebung. Führe sie aus, behebe Fehler, die durch die angeforderte Änderung verursacht wurden, und führe betroffene Tests erneut aus, ohne bei jedem Schritt eine Genehmigung anzufordern.

Grenzen für eigenständige Entscheidungen

Achte genau darauf, wie du Grenzen formulierst. Wenn ein früheres Modell ohne Erlaubnis in deinem Namen gehandelt hat, hast du möglicherweise nachdrückliche Formulierungen ergänzt, damit es zuerst nachfragt. Das kann sinnvoll sein. GPT-6 Astra ist jedoch unser am besten auf menschliche Absichten und Werte ausgerichtetes Modell und verfügt über ein deutlich besseres Urteilsvermögen. Es führt Aufgaben nur aus, wenn es weiß, dass dies sicher ist. Berücksichtige das im Umgang mit ihm.

Wenn du zuvor Grenzen gesetzt hast, um andere Modelle davon abzuhalten, zu weit zu gehen, und jetzt zu GPT-6 Astra wechselst, solltest du diese Formulierungen überdenken: Astra könnte sie zu ernst nehmen und die Arbeit unterbrechen, obwohl du eigentlich möchtest, dass es weitermacht.

Dranbleiben

Wenn du es gewohnt bist, dass GPT-5.6 Sol eine Anfrage aufgreift und über längere Zeit selbstständig daran arbeitet, kann GPT-6 Astra bei der Entscheidung, wann es aufhören soll, zögerlicher wirken. Es kann nach einer ersten Implementierung um deine Überprüfung bitten, obwohl noch Arbeit offen ist.

Hier hilft es, vor dem Start festzulegen, wann die Aufgabe abgeschlossen ist. Möglicherweise musst du Astra ausdrücklich dazu auffordern, bis zum vollständigen Abschluss weiterzuarbeiten. Wenn zur Aufgabe gehört, die Implementierung zum Laufen zu bringen, das Ergebnis zu prüfen und Fehler zu beheben, nimm das in deine Anfrage auf. Die Vorgabe, nach der ersten Implementierung zur Überprüfung anzuhalten, bringt das Modell dazu, früher aufzuhören. Prüfe deshalb, ob du an diesem Punkt tatsächlich selbst eine Entscheidung treffen musst.

Wenn das Modell nach einem ersten Durchgang weiter nachforschen soll, sage ihm, was es untersuchen und wann es aufhören soll.

Ein neues Modell ist eine gute Gelegenheit, aufzuräumen. Du musst aber nicht alles von Hand überprüfen: Bitte GPT-6 Astra, deine Anweisungen anhand der Punkte aus diesem Artikel zu prüfen. Entwickle dann etwas, an das du dich vorher nicht herangewagt hättest!