codex-issue-digest

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Codex Issue Digest

Codex Issue 摘要

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

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.

默认生成过去24小时内、按指定功能区域标签筛选的

openai/codex

仓库Issue摘要，采用标题优先、聚焦洞察的呈现方式。若用户指定其他时长（如“过去一周”或“48小时”），则按指定时长生成。默认仅返回摘要内容，仅在用户要求时才包含详细信息。

仅包含当前带有

bug

或

enhancement

标签，且至少带有一个指定负责人标签的Issue。若用户要求覆盖全区域或所有标签，则收集所有带有

bug

enhancement

标签的Issue。

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
```

功能区域标签，例如
```
tui exec
```
```
all areas
```
/
```
all labels
```
：扫描所有当前功能标签
可选仓库覆盖参数，默认值为
```
openai/codex
```
可选时间窗口参数，默认过去24小时；示例：
```
48h
```
、
```
7d
```
、
```
1w
```
、
```
past week
```

Workflow

工作流

Run the collector from a current Codex repo checkout:

bash

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

Use

--window "past week"

--window-hours 168

when the user asks for a non-default duration. Use

--all-labels

when the user says all areas or all labels.

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
```
.
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.
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:

markdown

undefined

从当前Codex仓库检出目录运行收集脚本：

bash

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

若用户要求非默认时长，使用

--window "past week"

或

--window-hours 168

参数。若用户要求全区域或所有标签，使用

--all-labels

参数。

将生成的JSON作为权威数据源，其中包含新增Issue、新增Issue评论、新增反应/点赞、当前标签、当前反应计数、供模型使用的
```
summary_inputs
```
以及详细的
```
digest_rows
```
。
根据用户请求选择输出模式：
- 默认模式：报告以
```
## Summary
```
  开头，不输出
```
## Details
```
  部分。
- 详情优先模式：若用户要求查看详情、表格、完整摘要或类似需求（如“包含详情”），则先输出
```
## Summary
```
  ，再包含
```
## Details
```
  部分。
- 后续详情模式：若用户在仅查看摘要后要求更多详情，当现有收集脚本生成的JSON仍可用时，直接从中生成
```
## Details
```
  ；否则重新运行收集脚本。
在
```
## Summary
```
部分，撰写标题优先的执行摘要：
- ```
## Summary
```
  下的第一行非空内容必须是单行标题或判断，不能是项目符号。即使读者只看到这里，该内容也应具备参考价值。
- 当无重要问题时，统一使用：
```
No major issues reported by users.
```
  （用户未报告重大问题）。适用于无高关注度条目、无新出现的重复主题且无需负责人处理的情况。
- 当用户反馈值得关注的问题时，标题需明确问题数量或主题，例如
```
Two issues are being surfaced by users:
```
  （用户反馈了两个问题：）。
- 在有效标题下方，仅列出引发关注的问题或主题，按重要性排序。若条目带有
```
attention_marker
```
  ，则以该标记开头，后跟简洁的、供负责人阅读的描述以及内嵌Issue引用。
- 将
```
🔥🔥
```
  视为值得放入标题的高关注度标记，
```
🔥
```
  视为较高关注度标记。请勿自行添加火焰表情，仅复制条目中的
```
attention_marker
```
  。
- 标题后的额外摘要内容需控制在1-3行简洁文字，仅当内容涉及决策相关的注意事项、重复主题或负责人需采取的行动时才添加。
- 常规计数、宽泛统计或低信号表格摘要请勿放入
```
## Summary
```
  ，除非这些内容会改变标题。元数据和可选计数应放入
```
## Details
```
  或页脚。
- 默认模式下，报告结尾需添加简洁提示，例如
```
Want details? I can expand this into the issue table.
```
  （需要详情吗？我可以展开为Issue表格。），该提示需与摘要标题分开，保持标题简洁。
- 从
```
summary_inputs
```
  中自行归类并命名主题；收集脚本未硬编码Issue分类。
- 仅当问题确实属于同一产品问题时才进行归类。若多个问题仅共享宽泛的平台或标签，则单独描述每个问题。
- 即使单个问题未达到详情表格的筛选阈值，也请勿忽略重复出现的主题。多个类似报告应作为重复的用户关注点被提及。
- 对于单个Issue条目，直接总结问题，无需归类。
- 使用相关条目中
```
ref_markdown
```
  提供的内嵌编号Issue链接。
- 无重要问题的摘要示例：

markdown

undefined

Summary

No major issues reported by users.

Source: collector v5, git

abc123def456

, window

2026-04-27T00:00:00Z

2026-04-28T00:00:00Z

. Want details? I can expand this into the issue table.


   - Example active summary:

```markdown

No major issues reported by users.

Source: collector v5, git

abc123def456

, window

2026-04-27T00:00:00Z

2026-04-28T00:00:00Z

. Want details? I can expand this into the issue table.


   - 有重要问题的摘要示例：

```markdown

Summary

Two issues are being surfaced by users: 🔥🔥 Terminal launch hangs on startup 1 🔥 Resume switches model providers unexpectedly 2

Source: collector v5, git

abc123def456

, window

2026-04-27T00:00:00Z

2026-04-28T00:00:00Z

. Want details? I can expand this into the issue table.

5. In `## Details`, when details are requested, include a compact table only when useful:
   - Prefer rows from `digest_rows`; include a `Refs` column using each row's `ref_markdown`.
   - Keep the table short; omit low-signal rows when the summary already covers them.
   - Use compact columns such as marker, area, type, description, interactions, and refs.
   - The `Description` cell should be a short owner-readable phrase. Use row `description`, title, body excerpts, and recent comments, but do not mechanically copy the raw GitHub issue title when it contains incidental details.
   - A clear quiet/no-concern sentence when there is no meaningful signal.
6. Use the JSON `attention_marker` exactly. It is empty for normal rows, `🔥` for elevated rows, and `🔥🔥` for very high-attention rows. The actual cutoffs are in `attention_thresholds`.
7. Use inline numbered references where a row or bullet points to issues, for example `Compaction bugs [1](https://github.com/openai/codex/issues/123), [2](https://github.com/openai/codex/issues/456)`. Do not add a separate footnotes section.
8. Label `interactions` as `Interactions`; it counts unique human GitHub users who created a new issue, added a new comment, or reacted during the requested window. Multiple posts/reactions from the same user on the same issue count once.
9. Mention the collector `script_version`, repo checkout `git_head`, and time window in one compact source line. In default mode, put this before the details prompt so the final line still asks whether the user wants details. In details-upfront mode, it can be the footer.

Two issues are being surfaced by users: 🔥🔥 Terminal launch hangs on startup 1 🔥 Resume switches model providers unexpectedly 2

Source: collector v5, git

abc123def456

, window

2026-04-27T00:00:00Z

2026-04-28T00:00:00Z

. Want details? I can expand this into the issue table.

5. 当用户要求查看详情时，在`## Details`部分仅在必要时包含简洁表格：
   - 优先使用`digest_rows`中的条目；使用每个条目的`ref_markdown`添加`Refs`列。
   - 表格需简洁；若摘要已涵盖低信号条目，则省略这些条目。
   - 使用紧凑列，例如标记、区域、类型、描述、互动数、引用。
   - `Description`单元格应为简洁的、供负责人阅读的短语。可使用条目中的`description`、标题、正文摘录及近期评论，但当GitHub Issue原始标题包含无关细节时，请勿机械复制。
   - 当无有效信号时，需添加清晰的说明语句（如“无相关问题反馈”）。
6. 严格使用JSON中的`attention_marker`：普通条目为空，较高关注度条目为`🔥`，极高关注度条目为`🔥🔥`。具体阈值定义在`attention_thresholds`中。
7. 当条目或项目符号指向Issue时，使用内嵌编号引用，例如`Compaction bugs [1](https://github.com/openai/codex/issues/123), [2](https://github.com/openai/codex/issues/456)`。请勿添加单独的脚注部分。
8. 将`interactions`标注为`Interactions`（互动数）；统计在指定时间窗口内创建新Issue、添加新评论或进行反应（包括点赞）的唯一GitHub人类用户数量。同一用户在同一Issue上的多次操作仅计为一次。
9. 在一行紧凑的来源说明中提及收集脚本的`script_version`、仓库检出的`git_head`及时间窗口。默认模式下，将该说明放在详情提示之前，确保最后一行仍是询问用户是否需要详情。详情优先模式下，该说明可放在页脚。

Reaction Handling

反应处理

The collector uses GitHub reactions endpoints, which include

created_at

, to count reactions created during the digest window for hydrated issues. It reports both in-window reaction counts and current reaction totals. Treat current reaction totals as standing engagement, and treat

new_reactions

new_upvotes

as windowed activity.

By default, the collector fetches issue comments with

since=<window start>

and caps the number of comment pages per issue. This keeps very long historical threads from dominating a digest run and focuses the report on recent posts. Use

--fetch-all-comments

only when exhaustive comment history is more important than runtime.

GitHub issue search is still seeded by issue

updated_at

, so a purely reaction-only issue may be missed if reactions do not bump

updated_at

. Covering every reaction-only case would require either a persisted snapshot store or a broader scan of labeled issues.

收集脚本使用GitHub反应接口（包含

created_at

字段）统计在摘要时间窗口内，已加载的Issue收到的反应数量。同时报告窗口内的反应计数和当前反应总数。将当前反应总数视为持续参与度，

new_reactions

new_upvotes

视为窗口内的活动量。

默认情况下，收集脚本使用

since=<window start>

参数获取Issue评论，并限制每个Issue的评论页数。这可避免过长的历史讨论占据摘要内容，使报告聚焦于近期帖子。仅当完整评论历史比运行时间更重要时，才使用

--fetch-all-comments

参数。

GitHub Issue搜索仍以Issue的

updated_at

字段为依据，因此若仅收到反应但未更新

updated_at

的Issue可能会被遗漏。要覆盖所有仅收到反应的情况，需使用持久化快照存储或对带标签的Issue进行更广泛的扫描。

Attention Markers

关注度标记

The collector scales attention markers by the requested time window. The baseline is 5 unique human users for

🔥

and 10 unique human users for

🔥🔥

over 24 hours; longer or shorter windows scale those cutoffs linearly and round up. For example, a one-week report uses 35 and 70 interactions. Unique human users are users who authored a new issue, authored a new comment, or reacted during the window, including upvotes. Multiple actions from the same user on the same issue count once. Bot posts and bot reactions are excluded. In prose, explain this as high user interaction rather than naming the emoji.

收集脚本会根据请求的时间窗口调整关注度标记的阈值。基线为24小时内，5个唯一人类用户对应

🔥

，10个唯一人类用户对应

🔥🔥

；时间窗口更长或更短时，阈值会按线性比例向上取整调整。例如，一周报告的阈值为35和70次互动。唯一人类用户指在窗口内创建新Issue、添加新评论或进行反应（包括点赞）的用户。同一用户在同一Issue上的多次操作仅计为一次。排除机器人的发帖和反应。在文字说明中，应将其描述为高用户互动，而非直接提及表情符号。

Freshness

时效性

The automation should run from a repo checkout that contains this skill. For shared daily use, prefer one of these patterns:

Run the automation in a checkout that is refreshed before the automation starts, for example with
```
git pull --ff-only
```
.
If the automation cannot safely mutate the checkout, have it report the current
```
git_head
```
from the collector output so readers know which skill/script version produced the digest.

自动化脚本应从包含该技能的仓库检出目录运行。对于日常共享使用，优先采用以下模式之一：

在自动化脚本启动前刷新仓库检出目录，例如执行
```
git pull --ff-only
```
，然后运行自动化脚本。
若自动化脚本无法安全修改检出目录，则在收集脚本输出中报告当前的
```
git_head
```
，以便读者了解生成摘要所使用的技能/脚本版本。

Sample Owner Prompt

负责人示例指令

text

Use $codex-issue-digest to run the Codex issue digest for labels tui and exec over the previous 24 hours.

text

Use $codex-issue-digest to run the Codex issue digest for all areas over the past week.

text

Use $codex-issue-digest to run the Codex issue digest for labels tui and exec over the previous 24 hours.

text

Use $codex-issue-digest to run the Codex issue digest for all areas over the past week.

Validation

验证

Dry run the collector against recent issues:

bash

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

bash

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

Run the focused script tests:

bash

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

针对近期Issue进行收集脚本的试运行：

bash

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

bash

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

运行脚本的专项测试：

bash

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