codex-issue-digest

Codex Issue Digest

Objective

Produce a headline-first, insight-oriented digest of openai/codex issues for the requested feature-area labels over the previous 24 hours by default. Honor a different duration when the user asks for one, for example "past week" or "48 hours". Default to a summary-only response; include details only when requested.

Include only issues that currently have bug or enhancement plus at least one requested owner label. If the user asks for all areas or all labels, collect bug/enhancement issues across all labels.

Inputs

• Feature-area labels, for example tui exec
• all areas / all labels to scan all current feature labels
• Optional repo override, default openai/codex
• Optional time window, default previous 24 hours; examples: 48h, 7d, 1w, past week

Workflow

1. Run the collector from a current Codex repo checkout:

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

Use --window "past week" or --window-hours 168 when the user asks for a non-default duration. Use --all-labels when the user says all areas or all labels.

1. Use the JSON as the source of truth. It includes new issues, new issue comments, new reactions/upvotes, current labels, current reaction counts, model-ready summary_inputs, and detailed digest_rows.
2. Choose the output mode from the user's request:
   • Default mode: start the report with ## Summary and do not emit ## Details.
   • Details-upfront mode: if the user asks for details, a table, a full digest, "include details", or similar, start with ## Summary, then include ## Details.
   • Follow-up details mode: if the user asks for more detail after a summary-only digest, produce ## Details from the existing collector JSON when it is still available; otherwise rerun the collector.
3. In ## Summary, write a headline-first executive summary:
   • The first nonblank line under ## Summary must be a single-line headline or judgment, not a bullet. It should be useful even if the reader stops there.
   • On quiet days, prefer exactly: No major issues reported by users. Use this when there are no elevated rows, no newly repeated theme, and nothing that needs owner action.
   • When users are surfacing notable issues, make the headline name the count or theme, for example Two issues are being surfaced by users:.
   • Immediately under an active headline, list only the issues or themes driving attention, ordered by importance. Start each line with the row's attention_marker when present, then a concise owner-readable description and inline issue refs.
   • Treat 🔥🔥 as headline-worthy and 🔥 as elevated. Do not add fire emoji yourself; only copy the row's attention_marker.
   • Keep any extra summary detail after the headline to 1-3 terse lines, only when it adds a decision-relevant caveat, repeated theme, or owner action.
   • Do not include routine counts, broad stats, or low-signal table summaries in ## Summary unless they change the headline. Put metadata and optional counts in ## Details or the footer.
   • In default mode, end the report with a concise prompt such as Want details? I can expand this into the issue table. Keep this separate from the summary headline so the headline stays clean.
   • Cluster and name themes yourself from summary_inputs; the collector intentionally does not hard-code issue categories.
   • Use a cluster only when the issues genuinely share the same product problem. If several issues merely share a broad platform or label, describe them individually.
   • Do not omit a repeated theme just because its individual issues fall below the details table cutoff. Several similar reports should be called out as a repeated customer concern.
   • For single-issue rows, summarize the concern directly instead of calling it a cluster.
   • Use inline numbered issue links from each relevant row's ref_markdown.
   • Example quiet summary: