GPT-6 Astra stoppt ständig? AGENTS.md und Skills vereinfachen
Ein praktisches Audit unnötiger Astra-Stopps: geladene Anweisungen prüfen, Approval-Gates entfernen, Skills begrenzen und eine kontrollierte Aufgabe vergleichen.
Inhalt

Wenn GPT-6 Astra öfter fragt als GPT-5.6 Sol, prüfen Sie zuerst, ob die Antwort das Ergebnis wesentlich verändern kann. Dann ist die Klärung richtig. Fragt das Modell vor dem Lesen einer Datei um Erlaubnis, liefert statt einer bereits autorisierten Änderung nur einen Plan oder startet nach einer Dokumentationsänderung die gesamte Testsuite, liegt die wahrscheinliche Ursache in den geladenen Anweisungen: AGENTS.md, einem verschachtelten Override oder einem zu breiten Skill.
OpenAI beschreibt beide Seiten: Astra klärt Entscheidungen mit möglichem Einfluss häufiger und folgt langen Anweisungen genauer. Daher wirkt eine mehrdeutige oder widersprüchliche Regel stärker. Prüfen Sie die tatsächliche Kette, behalten Sie dauerhafte Regeln und wiederholen Sie dieselbe begrenzte Aufgabe.
Am 6. September 2026 führte BetterToken gpt-6-astra in der Gruppe GPT; die Verbindung zu Codex erfolgt als custom provider über die Responses API.
GPT-6 Astra über BetterToken mit Codex verbinden
Das aktuelle Setup steht in der BetterToken-Anleitung für Codex. BetterToken liefert die Verbindung; Ihre Konfiguration und Aufgabe bestimmen geladene Regeln und Fragen.
Alle tatsächlich sichtbaren Anweisungen finden
Codex baut die Kette beim Sitzungsstart auf. Nach den offiziellen AGENTS.md-Regeln liest es:
- globales
AGENTS.override.mdoder andernfalls globalesAGENTS.md; - höchstens eine Datei pro Verzeichnis vom Projektstamm bis zum CWD: zuerst
AGENTS.override.md, dannAGENTS.md, danach Einträge ausproject_doc_fallback_filenames, bis die erste nicht leere Datei gefunden ist; - Regeln näher am CWD später, sodass sie frühere Regeln ersetzen können.
Leere Dateien werden übersprungen. project_doc_max_bytes begrenzt die kombinierten Projektanweisungen standardmäßig auf 32 KiB; eine lange Root-Datei kann spezifische Regeln verdrängen.
Starten Sie eine neue Sitzung im selben Verzeichnis:
codex --ask-for-approval never "List the instruction sources you loaded."
Prüfen Sie project_doc_fallback_filenames und alle möglichen Fallback-Dateien. Notieren Sie außerdem aktive Skills und die Quelle jedes gewählten Skills: Codex kann sie an repository-, user-, admin- und system-Standorten finden. Sichern Sie diesen Baseline-Zustand vor der Bearbeitung.
Jede Regel mit vier Fragen markieren
| Feld | Frage |
|---|---|
| Scope | Gilt sie für alle Repositories, das Projekt oder ein Verzeichnis? |
| Trigger | Welche konkrete Aufgabe aktiviert sie? |
| Action | Was muss Codex tun? |
| Stop | Muss es stoppen und auf den Nutzer warten? |
Regeln ohne klaren Trigger erzeugen Stopps: Always ask before making changes, Use every relevant skill, Run all tests before finishing, Do not make assumptions oder mehrere Dateien mit angeblicher Höchstpriorität. Behalten Sie stop conditions bei irreversibler Löschung, Veröffentlichung, bezahlter Aktion, inkompatibler Architekturwahl oder fehlendem Secret. Lesen, lokale Änderungen und zielgerichtete Tests brauchen nach der Beauftragung meist keine weitere Zustimmung.
AGENTS.md kurz und dauerhaft halten
Eine problematische Root-Datei versucht jeden Fall vorzuschreiben:
AGENTS.md
- Always ask the user before changing any file.
- Always create a detailed plan and wait for approval.
- Use all available skills that may be relevant.
- Run the full test suite after every change.
- Never make assumptions.
- Never stop until everything in the repository is fixed.
Diese Regeln widersprechen sich bei Autonomie, Scope und Tests. Eine bessere Grundlage definiert Ergebnis und Grenzen:
AGENTS.md
## Working agreement
- Complete the user's requested outcome with the smallest correct change.
- Treat the user's current instruction as higher priority than reusable workflow guidance.
- Make routine, reversible assumptions when they do not change the requested outcome; state material assumptions.
- Ask only when a missing choice would materially change the result or authorization.
- Preserve unrelated work and do not expand scope to optional cleanup.
- Run checks proportionate to the changed behavior; broaden only when evidence justifies it.
- Stop after the requested result and relevant checks are complete.
Ergänzen Sie nur dauerhafte Befehle, Commit-Konventionen und Verbote. Regeln eines Dienstes gehören in dessen Nähe. Ein temporäres AGENTS.override.md ersetzt das AGENTS.md im selben Verzeichnis und ergänzt es nicht. Kopieren Sie Pflichtregeln in den Override oder verwenden Sie ein verschachteltes AGENTS.md; löschen Sie den Override nach dem Experiment.
Inhalte richtig verteilen
| Inhalt | Ort |
|---|---|
| Dauerhafte Projektregel | Root-AGENTS.md |
| Regel für Verzeichnis oder Dienst | verschachteltes AGENTS.md oder AGENTS.override.md |
| Seltener Ablauf mit präzisem Trigger | ein enger Skill |
| Parsing, Formatierung und Schema-Prüfung | Script oder Hook |
| Umfangreiche Referenzen und Beispiele | references/ des gewählten Skills |
Codex Skills nutzt Progressive Disclosure: zuerst Name und Beschreibung, dann bei Auswahl das vollständige SKILL.md. Geben Sie jedem Skill eine Aufgabe und nennen Sie Trigger sowie Grenze zuerst:
---
name: release-preview
description: >-
Use only when the user asks to build a local release preview; do not publish,
deploy, push, or change production state.
---
SKILL.md enthält Inputs, Outputs, imperative Schritte und stop conditions; große Beispiele kommen in References, deterministische Aktionen in Scripts. Testen Sie die Beschreibung mit einem auslösenden und zwei ähnlichen, nicht auslösenden Prompts. Reagieren zwei Skills auf dieselbe Anfrage, trennen Sie Trigger oder führen Sie Duplikate zusammen.
Autonomie und Prüfung festlegen
Die Astra-Anleitung empfiehlt, das implizite Ergebnis fertigzustellen, die aktuelle Nutzeranweisung zu priorisieren, nur bei wesentlichen Auswirkungen zu fragen und Checks nach Risiko zu wählen. Kopieren Sie den Block nicht in jeden Skill. Regeln für Subagents brauchen unabhängige Teilaufgaben, genug Umfang und eine klare Zusammenführung; „immer mehrere Agents“ schadet kleinen Aufgaben.
Ein identisches Fixture wiederholen
Update one configuration field in docs/setup.md, preserve all unrelated files,
run the Markdown link check for that file, and report the changed path.
Führen Sie es vorher und nachher im selben Verzeichnis mit gleichem Modell, gleichen permissions und gleichem Zustand aus. Erfassen Sie Fragen, notwendige Eingriffe, geladene Dateien und Skills, Checks sowie fremde Änderungen. Verbesserung bedeutet nicht null Fragen: Wesentliche Entscheidungen brauchen Rückfragen, Routineentscheidungen Fortschritt, Änderungen ausreichende Prüfung und klare Grenzen.
Für diesen Artikel wurde der Replay nicht in einem Nutzer-Repository ausgeführt; eine feste Reduktion wird nicht versprochen. Die Methode liefert beobachtbare Signale, um Modellverhalten von einer konkreten Anweisung zu trennen.