$npx -y skills add openai/codex --skill codex-issue-digestRun a GitHub issue digest for openai/codex by feature-area labels, all areas, and configurable time windows. Use when asked to summarize recent Codex bug reports or enhancement requests, especially for owner-specific labels such as tui, exec, app, or similar areas.
| 1 | # Codex Issue Digest |
| 2 | |
| 3 | ## Objective |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | ## Inputs |
| 10 | |
| 11 | - Feature-area labels, for example `tui exec` |
| 12 | - `all areas` / `all labels` to scan all current feature labels |
| 13 | - Optional repo override, default `openai/codex` |
| 14 | - Optional time window, default previous 24 hours; examples: `48h`, `7d`, `1w`, `past week` |
| 15 | |
| 16 | ## Workflow |
| 17 | |
| 18 | 1. Run the collector from a current Codex repo checkout: |
| 19 | |
| 20 | ```bash |
| 21 | python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --labels tui exec --window-hours 24 |
| 22 | ``` |
| 23 | |
| 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. |
| 25 | |
| 26 | 2. 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`. |
| 27 | 3. Choose the output mode from the user's request: |
| 28 | - Default mode: start the report with `## Summary` and do not emit `## Details`. |
| 29 | - Details-upfront mode: if the user asks for details, a table, a full digest, "include details", or similar, start with `## Summary`, then include `## Details`. |
| 30 | - 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. |
| 31 | 4. In `## Summary`, write a headline-first executive summary: |
| 32 | - 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. |
| 33 | - 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. |
| 34 | - When users are surfacing notable issues, make the headline name the count or theme, for example `Two issues are being surfaced by users:`. |
| 35 | - 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. |
| 36 | - Treat `🔥🔥` as headline-worthy and `🔥` as elevated. Do not add fire emoji yourself; only copy the row's `attention_marker`. |
| 37 | - 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. |
| 38 | - 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. |
| 39 | - 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. |
| 40 | - Cluster and name themes yourself from `summary_inputs`; the collector intentionally does not hard-code issue categories. |
| 41 | - 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. |
| 42 | - 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. |
| 43 | - For single-issue rows, summarize the concern directly instead of calling it a cluster. |
| 44 | - Use inline numbered issue links from each relevant row's `ref_markdown`. |
| 45 | - Example quiet summary: |
| 46 | |
| 47 | ```markdown |
| 48 | ## Summary |
| 49 | No major issues reported by users. |
| 50 | |
| 51 | Source: collector v5, git `abc123def456`, window `2026-04-27T00:00:00Z` to `2026-04-28T00:00:00Z`. |
| 52 | Want details? I can expand this into the issue table. |
| 53 | ``` |
| 54 | |
| 55 | - Example active summary: |
| 56 | |
| 57 | ```markdown |
| 58 | ## Summary |
| 59 | Two issues are being surfaced by users: |
| 60 | 🔥🔥 Terminal launch hangs on startup [1](https://github.com/openai/codex/issues/123) |
| 61 | 🔥 Resume switches model providers unexpectedly [2](https://github.com/openai/codex/issues/456) |
| 62 | |
| 63 | Source: collector v5, git `abc123def456`, window `2026-04-27T00:00:00Z` to `2026-04-28T00:00:00Z`. |
| 64 | Want details? I can expand this into the issue table. |
| 65 | ``` |
| 66 | 5. In `## Deta |