perhapsspy/codex-token-discipline

Codex Token-Disziplin

Zweck

Reduziert die Gesamtkosten für Root- und Child-Sessions, ohne den Erfolg der Aufgabe, die erforderlichen Nachweise oder das geforderte Ergebnis zu schwächen.

Halte Lesevorgänge, Werkzeugausgaben, Wiederholungen und Delegationen begrenzt. Bewahre wiederverwendbare Nachweise auf und eskaliere nur den ungelösten Teil.

Betriebsrahmen

Verwende nur, was das Verhalten ändert:

1. Benenne die aktuelle Phase: erkunden, planen, implementieren, verifizieren, veröffentlichen oder übergeben.
2. Definiere den nächsten benötigten Nachweis, bevor du breit liest.
3. Definiere vor einem potenziell rauschintensiven Werkzeugaufruf die kleinste nützliche Rückgabeform und das Ausgabebudget.
4. Delegiere rauschintensive Nebenarbeiten nur, wenn sie destillierte Ergebnisse mit Nachweisen zurückgeben können.
5. Speichere an Phasengrenzen einen kompakten Wiederaufnahmezustand und übergib die Entscheidungen zur Sitzungsfortsetzung an den verantwortlichen Director, falls vorhanden.

Überspringe das Ritual bei kleinen Änderungen, direkten Antworten und einfachen Befehlen.

Preflight-Output-Vertrag

Verhindere übermäßige Ausgabe, bevor sie in den Hauptkontext gelangt; verlasse dich nicht auf eine nachträgliche Zusammenfassung.

• Benenne für jeden unvorhersehbaren oder Batch-Befehl zuerst die erforderliche Rückgabeform: Status, Anzahl, Pfade, ausgewählte Felder oder den ersten ausführbaren Fehler.
• Setze ein endliches Rückgabebudget für den Werkzeugaufruf. Verwende für exec-ähnliche Aufrufe standardmäßig ein explizites Budget von höchstens 2.000 Tokens, es sei denn, benannte Nachweise erfordern mehr; warte nicht auf eine einzelne Schwelle für große Ausgaben.
• Filtere, aggregiere oder selektiere an der Quelle. Gib für Tests und Builds den Exit-Status, den ersten ausführbaren Fehler und den Befehl zurück, bevor du weitere Details anforderst.
• Wenn die vollständige Ausgabe für eine spätere Überprüfung nützlich ist, schreibe sie in ein aufgabenlokales oder temporäres Artefakt und gib nur dessen Pfad, Größe, kompakte Zusammenfassung und den ersten ausführbaren Fehler zurück. Untersuche bei Bedarf begrenzte Ausschnitte aus dem Artefakt.
• Erstelle kein Artefakt für wegwerfbare Ausgaben, die an der Quelle reduziert werden können.

Zusammenfassung-zuerst-Lesen

Beginne eng; weite nur, wenn es die nächste Entscheidung beeinflusst.

• Suche mit rg oder Dateilisten, bevor du Dateien öffnest.
• Bevorzuge git diff --stat, git diff --name-only, fokussiertes git diff -- <pfad> und gezielte sed -n-Bereiche vor vollständigen Diffs.
• Verwende für Logs und Befehlsausgaben tail, head, jq, Zählungen, Filter oder Fehlersuchen vor vollständigen Transkripten.
• Behandle jedes zurückgegebene Werkzeugergebnis als zukünftige Eingabekosten. Bevorzuge Zählungen, Pfade, Zusammenfassungen oder ausgewählte Nachweise vor vollständigen Ausgaben.
• Weite nach einem Fehler aus dem gespeicherten Artefakt oder führe nur den kleinsten fehlschlagenden Bereich erneut aus; vermeide wiederholte vollständige Transkripte im Hauptthread.

Wenn ein breites Lesen notwendig ist, begründe dies und begrenze es auf den kleinsten nützlichen Umfang.

Langlaufende Arbeiten

Behandle Phasenwechsel als Kontext-Checkpoints.

• Bewahre vor Implementierungs- oder Repository-/Aufgabenwechseln die Schlussfolgerung, die nächste Entscheidung, den nächsten Schritt und die kleinste nützliche Grenze auf.
• Verwende in Repositories mit project-context bevorzugt BRIEF.md für den kompakten aktuellen Zustand und Logs für Nachweise.
• Wenn ein Director langlaufende Arbeiten koordiniert, melde den Checkpoint und lasse den Director entscheiden, ob die Sitzung fortgesetzt, übergeben oder rotiert wird. Verschreibe oder initiiere nicht bedingungslos eine neue Sitzung.
• Ohne Director starte nur dann neu, wenn die gespeicherte Oberfläche ausreicht, um fortzufahren, und der Benutzer oder der eigene Workflow dies erfordert.

Speichere keine Transkripte, Validierungsmatrizen oder Dateiinventare, um ein großes Gespräch zu kompensieren.

Unteragenten

Delegation ist nicht inhärent günstiger. Verwende den engsten benannten Agenten für begrenzte Arbeiten, die kompakte, unabhängig nützliche Nachweise oder Ausgaben zurückgeben können.

Beginne mit einem Agenten. Parallelisiere nur unabhängige, sich nicht überschneidende Bereiche. Dupliziere keine gleiche Untersuchung, halte Agenten nicht nach der Integration am Leben und wiederhole keine noch gültigen Validierungen.

Gib den Umfang, die Schreibgrenze, die Fertigstellungsbedingung, die Validierung und die erwartete kompakte Ausgabe vor. Kinder dürfen nicht delegieren.

Browser- und UI-Schleifen

Notiere vor wiederholter visueller oder Browser-Verifizierung die zu prüfenden Zustände.

• Bevorzuge einen Screenshot oder Browser-Durchlauf pro benanntem Zustand.
• Wenn eine Prüfung fehlschlägt, untersuche den kleinsten Besitzer: Konsolenfehler, DOM-Zustand, Routendaten oder fokussierte Komponente.
• Halte Bilder, Base64-Screenshots, vollständigen Body-Text und DOM-Dumps aus dem Hauptthread heraus, es sei denn, dieses Artefakt selbst beeinflusst die nächste Entscheidung.
• Stoppe, sobald die benannten Zustände verifiziert oder ein konkreter Blocker isoliert ist.

Immer-gelesene Oberflächen

Jede Zeile in globalen oder Repository-Anweisungen verursacht wiederkehrende Kosten.

• Platziere dauerhafte Verhaltensregeln und Sicherheitsgrenzen in AGENTS-ähnlichen Dateien.
• Platziere wiederholbare Workflows in Fähigkeiten.
• Platziere den aktuellen Aufgabenstatus in Repository-Aufgabendokumenten.
• Platziere aktuelle wiederverwendbare Domänenfakten in Referenzdokumenten.
• Entferne veraltete Profile, doppelte Anweisungen und historische Erklärungen, anstatt sie zu dokumentieren.

Wenn du eine immer-gelesene Datei bearbeitest, bevorzuge eine kurze Routing-Regel gegenüber Prozedurtext.

Nutzungsprüfung

Wenn gefragt wird, wohin Tokens geflossen sind, löse scripts/summarize_codex_usage.py relativ zu diesem installierten Fähigkeitsverzeichnis auf, führe es mit --help aus und prüfe dann mit einem expliziten --cwd-prefix.

Das Skript gruppiert Codex-Rollout-Logs nach Root-Thread und meldet Token-Summen, Cache-Input-Rate, Child-Session-Token-Anteil, Tool-Output-Volumen, Ereignisse mit großen Ausgaben und Signale für Top-Output-Tools ohne Rohdaten.

Behandle Token-Summen als Signale, nicht als Qualität. Vermeide hausweite Textsuchen; weise das Skript auf $CODEX_HOME/sessions oder ein anderes explizites Sessions-Root-Verzeichnis.

Abschlussprüfung

• Hat der Hauptthread nur die für die aktuelle Entscheidung benötigten Nachweise erhalten?
• Hatten rauschintensive Werkzeugarbeiten vor der Ausführung eine Rückgabeform und ein Budget, wobei vollständige Details nur dann in einem Artefakt gespeichert wurden, wenn dies nützlich war?
• Waren große Lesevorgänge, Browser-Schleifen und Unteragenten durch explizite Fragen begrenzt?
• Befindet sich der wiederaufnehmbare Zustand auf der richtigen Oberfläche und hat der verantwortliche Director die Entscheidung über Fortsetzung/Übergabe/Rotation behalten?
• Blieb die immer-gelesene Anleitung kurz und leitete Details anderswohin?