codex-issue-digest

Codex Issue Digest

Ziel

Erstelle eine schlagzeilenorientierte, erkenntnisreiche Zusammenfassung der openai/codex-Issues für die angeforderten Feature-Area-Labels der letzten 24 Stunden (Standard). Verwende einen anderen Zeitraum, wenn der Benutzer danach fragt, z.B. „vergangene Woche“ oder „48 Stunden“. Standardmäßig wird nur eine Zusammenfassung ausgegeben; Details nur auf Anfrage.

Berücksichtige nur Issues, die aktuell bug oder enhancement sowie mindestens ein angefordertes Owner-Label haben. Fragt der Benutzer nach allen Bereichen oder allen Labels, erfasse bug-/enhancement-Issues über alle Labels hinweg.

Eingaben

• Feature-Area-Labels, z.B. tui exec
• all areas / all labels zum Durchsuchen aller aktuellen Feature-Labels
• Optionales Repo-Override, Standard openai/codex
• Optionales Zeitfenster, Standard 24 Stunden; Beispiele: 48h, 7d, 1w, letzte Woche

Arbeitsablauf

1. Führe den Collector von einem aktuellen Codex-Repo-Checkout aus:

python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --labels tui exec --window-hours 24

Verwende --window "letzte Woche" oder --window-hours 168, wenn der Benutzer eine nicht standardmäßige Dauer wünscht. Verwende --all-labels, wenn der Benutzer „alle Bereiche“ oder „alle Labels“ sagt.

2. Verwende das JSON als Quelle der Wahrheit. Es enthält neue Issues, neue Issue-Kommentare, neue Reaktionen/Upvotes, aktuelle Labels, aktuelle Reaktionsanzahlen, modellbereite summary_inputs und detaillierte digest_rows.
3. Wähle den Ausgabemodus basierend auf der Anfrage des Benutzers:
   • Standardmodus: Beginne den Bericht mit ## Summary und gib kein ## Details aus.
   • Modus „Details zuerst“: Wenn der Benutzer nach Details, einer Tabelle, einer vollständigen Zusammenfassung, „Details einschließen“ oder ähnlichem fragt, beginne mit ## Summary und füge dann ## Details hinzu.
   • Modus „Folgedetails“: Wenn der Benutzer nach einer zusammenfassenden Zusammenfassung weitere Details wünscht, erstelle ## Details aus dem vorhandenen Collector-JSON, falls noch verfügbar; andernfalls führe den Collector erneut aus.
4. Schreibe in ## Summary eine schlagzeilenorientierte Executive Summary:
   • Die erste nicht leere Zeile unter ## Summary muss eine einzeilige Schlagzeile oder Einschätzung sein, kein Aufzählungspunkt. Sie sollte auch dann nützlich sein, wenn der Leser an dieser Stelle aufhört.
   • An ruhigen Tagen bevorzuge genau: Keine größeren Probleme von Benutzern gemeldet. Verwende dies, wenn es keine erhöhten Zeilen, kein neu wiederholtes Thema und nichts gibt, das eine Aktion des Owners erfordert.
   • Wenn Benutzer bemerkenswerte Issues ansprechen, mache die Schlagzeile zur Anzahl oder zum Thema, z.B. Zwei Issues werden von Benutzern hervorgehoben:.
   • Liste unmittelbar unter einer aktiven Schlagzeile nur die Issues oder Themen auf, die die Aufmerksamkeit lenken, geordnet nach Wichtigkeit. Beginne jede Zeile mit dem attention_marker der Zeile, falls vorhanden, dann einer präzisen, für den Owner lesbaren Beschreibung und Inline-Issue-Referenzen.
   • Behandle 🔥🔥 als schlagzeilenwürdig und 🔥 als erhöht. Füge selbst kein Feuer-Emoji hinzu; kopiere nur den attention_marker der Zeile.
   • Halte zusätzliche Zusammenfassungsdetails nach der Schlagzeile auf 1-3 knappe Zeilen beschränkt, nur wenn sie einen entscheidungsrelevanten Hinweis, ein wiederholtes Thema oder eine Owner-Aktion hinzufügen.
   • Füge keine routinemäßigen Zählungen, breiten Statistiken oder signalarme Tabellenzusammenfassungen in ## Summary ein, es sei denn, sie ändern die Schlagzeile. Platziere Metadaten und optionale Zählungen in ## Details oder der Fußzeile.
   • Beende den Bericht im Standardmodus mit einer prägnanten Aufforderung wie Möchtest du Details? Ich kann dies zur Issue-Tabelle erweitern. Halte dies getrennt von der Zusammenfassungsschlagzeile, damit die Schlagzeile sauber bleibt.
   • Bündele und benenne Themen selbst aus summary_inputs; der Collector vermeidet absichtlich hartcodierte Issue-Kategorien.
   • Verwende ein Cluster nur, wenn die Issues wirklich dasselbe Produktproblem teilen. Wenn mehrere Issues nur eine breite Plattform oder ein Label teilen, beschreibe sie einzeln.
   • Lasse ein wiederholtes Thema nicht weg, nur weil seine einzelnen Issues unterhalb des Detailtabellen-Cutoffs liegen. Mehrere ähnliche Berichte sollten als wiederholtes Kundenanliegen hervorgehoben werden.
   • Bei Ein-Issue-Zeilen fasse das Anliegen direkt zusammen, anstatt es als Cluster zu bezeichnen.
   • Verwende Inline-nummerierte Issue-Links aus dem ref_markdown der jeweiligen Zeile.
   • Beispiel für eine ruhige Zusammenfassung:

## Summary
Keine größeren Probleme von Benutzern gemeldet.

Quelle: Collector v5, git `abc123def456`, Fenster `2026-04-27T00:00:00Z` bis `2026-04-28T00:00:00Z`.
Möchtest du Details? Ich kann dies zur Issue-Tabelle erweitern.

• Beispiel für eine aktive Zusammenfassung:

## Summary
Zwei Issues werden von Benutzern hervorgehoben:
🔥🔥 Terminal hängt beim Start [1](https://github.com/openai/codex/issues/123)
🔥 Resume wechselt unerwartet den Modellanbieter [2](https://github.com/openai/codex/issues/456)

Quelle: Collector v5, git `abc123def456`, Fenster `2026-04-27T00:00:00Z` bis `2026-04-28T00:00:00Z`.
Möchtest du Details? Ich kann dies zur Issue-Tabelle erweitern.

5. In ## Details, wenn Details angefordert werden, füge nur dann eine kompakte Tabelle ein, wenn sie nützlich ist:
   • Bevorzuge Zeilen aus digest_rows; füge eine Spalte Refs mit dem ref_markdown jeder Zeile hinzu.
   • Halte die Tabelle kurz; lasse signalarme Zeilen weg, wenn die Zusammenfassung sie bereits abdeckt.
   • Verwende kompakte Spalten wie Marker, Bereich, Typ, Beschreibung, Interaktionen und Refs.
   • Die Zelle Beschreibung sollte eine kurze, für den Owner lesbare Phrase sein. Verwende Zeilenbeschreibung, Titel, Textauszüge und aktuelle Kommentare, kopiere jedoch nicht mechanisch den rohen GitHub-Issue-Titel, wenn dieser beiläufige Details enthält.
   • Ein klarer Satz für ruhige/keine Bedenken, wenn es kein aussagekräftiges Signal gibt.
6. Verwende den JSON-attention_marker genau. Er ist leer für normale Zeilen, 🔥 für erhöhte Zeilen und 🔥🔥 für Zeilen mit sehr hoher Aufmerksamkeit. Die tatsächlichen Schwellenwerte sind in attention_thresholds.
7. Verwende Inline-nummerierte Referenzen, wenn eine Zeile oder ein Aufzählungspunkt auf Issues verweist, z.B. Kompaktierungsfehler [1](https://github.com/openai/codex/issues/123), [2](https://github.com/openai/codex/issues/456). Füge keinen separaten Fußnotenabschnitt hinzu.
8. Bezeichne interactions als Interaktionen; es zählt eindeutige menschliche GitHub-Benutzer, die ein neues Issue erstellt, einen neuen Kommentar hinzugefügt oder während des angeforderten Fensters reagiert haben. Mehrere Beiträge/Reaktionen desselben Benutzers zum selben Issue werden einmal gezählt.
9. Erwähne die script_version des Collectors, den Repo-Checkout git_head und das Zeitfenster in einer kompakten Quellenzeile. Im Standardmodus platziere dies vor der Detailaufforderung, sodass die letzte Zeile immer noch fragt, ob der Benutzer Details wünscht. Im Modus „Details zuerst“ kann dies die Fußzeile sein.

Reaktionsbehandlung

Der Collector verwendet GitHub-Reaktionsendpunkte, die created_at enthalten, um Reaktionen zu zählen, die während des Digest-Fensters für hydrierte Issues erstellt wurden. Er meldet sowohl Reaktionsanzahlen im Fenster als auch aktuelle Reaktionssummen. Behandle aktuelle Reaktionssummen als laufendes Engagement und new_reactions / new_upvotes als gefensterte Aktivität.

Standardmäßig ruft der Collector Issue-Kommentare mit since=<Fensterstart> ab und begrenzt die Anzahl der Kommentarseiten pro Issue. Dadurch wird vermieden, dass sehr lange historische Threads einen Digest-Durchlauf dominieren, und der Fokus wird auf aktuelle Beiträge gelegt. Verwende --fetch-all-comments nur, wenn eine vollständige Kommentarhistorie wichtiger ist als die Laufzeit.

Die GitHub-Issue-Suche verwendet immer noch den updated_at-Zeitstempel, sodass ein reines Reaktions-Issue möglicherweise übersehen wird, wenn Reaktionen den updated_at nicht ändern. Die Abdeckung aller reinen Reaktionsfälle würde entweder einen persistenten Snapshot-Speicher oder einen breiteren Scan von Issues mit Labels erfordern.

Aufmerksamkeitsmarker

Der Collector skaliert die Aufmerksamkeitsmarker entsprechend dem angeforderten Zeitfenster. Die Basislinie liegt bei 5 eindeutigen menschlichen Benutzern für 🔥 und 10 eindeutigen menschlichen Benutzern für 🔥🔥 in 24 Stunden; längere oder kürzere Fenster skalieren diese Schwellenwerte linear und runden auf. Beispielsweise verwendet ein Ein-Wochen-Bericht 35 und 70 Interaktionen. Eindeutige menschliche Benutzer sind Benutzer, die ein neues Issue erstellt, einen neuen Kommentar verfasst oder während des Fensters reagiert haben, einschließlich Upvotes. Mehrere Aktionen desselben Benutzers zum selben Issue werden einmal gezählt. Bot-Beiträge und Bot-Reaktionen werden ausgeschlossen. Erkläre dies im Text als hohe Benutzerinteraktion, anstatt das Emoji zu nennen.

Aktualität

Die Automatisierung sollte von einem Repo-Checkout ausgeführt werden, das diese Skill enthielt. Für gemeinsame tägliche Nutzung bevorzuge eines dieser Muster:

• Führe die Automatisierung in einem Checkout aus, das vor Beginn der Automatisierung aktualisiert wird, z.B. mit git pull --ff-only.
• Wenn die Automatisierung das Checkout nicht sicher ändern kann, lasse sie den aktuellen git_head aus der Collector-Ausgabe melden, sodass die Leser wissen, welche Skill-/Skriptversion den Digest erstellt hat.

Beispiel für eine Owner-Aufforderung

Verwende $codex-issue-digest, um den Codex-Issue-Digest für die Labels tui und exec der letzten 24 Stunden auszuführen.

Verwende $codex-issue-digest, um den Codex-Issue-Digest für alle Bereiche der letzten Woche auszuführen.

Validierung

Führe einen Probelauf des Collectors mit aktuellen Issues durch:

python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --labels tui exec --window-hours 24

python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --all-labels --window "letzte Woche" --limit-issues 10

Führe die fokussierten Skript-Tests aus:

pytest .codex/skills/codex-issue-digest/scripts/test_collect_issue_digest.py