codex-issue-digest

Codex 问题摘要

目标

针对指定的功能领域标签，生成一份以标题为先、侧重洞察的 openai/codex 问题摘要，默认涵盖过去 24 小时。用户指定其他时长时，应按其要求处理，例如“过去一周”或“48 小时”。默认仅提供摘要；只有在用户要求时才包含详情。

仅纳入当前同时具有 bug 或 enhancement 标签，以及至少一个指定负责人标签的问题。如果用户要求查看所有领域或所有标签，则收集所有标签下的 bug/enhancement 问题。

输入

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

工作流

1. 在当前的 Codex 仓库检出目录中运行收集器：

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。

2. 以 JSON 为准。它包含新问题、新问题评论、新反应/赞、当前标签、当前反应计数、可供模型使用的 summary_inputs，以及详细的 digest_rows。
3. 根据用户的要求选择输出模式：
   • 默认模式：以 ## Summary 开始报告，不输出 ## Details。
   • 详情优先模式：如果用户要求详情、表格、完整摘要、“包含详情”或类似内容，则先输出 ## Summary，再输出 ## Details。
   • 后续补充详情模式：如果用户在仅含摘要的简报后要求更多详情，且现有收集器 JSON 仍可用，则根据它生成 ## Details；否则重新运行收集器。
4. 在 ## Summary 中撰写标题优先的执行摘要：
   • ## Summary 下方第一行非空内容必须是单行标题或判断，而不是项目符号。即使读者只看到这一行，也应能获取有用信息。
   • 在平静的日子，优先使用以下内容，且仅使用这一句：No major issues reported by users. 当没有值得关注的问题、没有新出现的重复主题，也没有需要负责人采取行动的事项时，使用此句。
   • 当用户提出了值得关注的问题时，标题应点明数量或主题，例如 Two issues are being surfaced by users:。
   • 在活跃问题标题正下方，仅列出引起关注的问题或主题，并按重要性排序。每行以对应条目的 attention_marker（如有）开头，然后简洁描述问题，并附上行内问题引用。
   • 将 🔥🔥 视为值得在标题中点出的信号，将 🔥 视为需要关注的信号。不要自行添加火焰表情；只能照抄条目中的 attention_marker。
   • 只有在补充内容有助于决策相关的注意事项、重复主题或负责人行动时，才在标题之后添加额外摘要，最多 1 至 3 行，并保持简洁。
   • 除非例行计数、整体统计或低信号量的表格摘要会改变标题，否则不要将其放入 ## Summary。元数据和可选计数应放在 ## Details 或页脚中。
   • 在默认模式下，以简洁的提示结束报告，例如 Want details? I can expand this into the issue table.。将此提示与摘要标题分开，以保持标题简洁。
   • 根据 summary_inputs 自行归纳并命名主题；收集器不会预先硬编码问题类别。
   • 仅当问题确实涉及同一个产品问题时，才将其归为同一主题。如果几个问题只是共享宽泛的平台或标签，则应分别描述。
   • 即使某个重复主题中的单个问题未达到详情表格的收录门槛，也不要遗漏该主题。应将多条相似报告列为重复出现的客户问题。
   • 对于只有一个问题的条目，应直接概述其问题，不要称其为主题组。
   • 使用每个相关条目的 ref_markdown 中的行内编号问题链接。
   • 平静摘要示例：

## Summary
No major issues reported by users.

Source: collector v5, git `abc123def456`, window `2026-04-27T00:00:00Z` to `2026-04-28T00:00:00Z`.
Want details? I can expand this into the issue table.

• 活跃摘要示例：

## Summary
Two issues are being surfaced by users:
🔥🔥 Terminal launch hangs on startup [1](https://github.com/openai/codex/issues/123)
🔥 Resume switches model providers unexpectedly [2](https://github.com/openai/codex/issues/456)

Source: collector v5, git `abc123def456`, window `2026-04-27T00:00:00Z` to `2026-04-28T00:00:00Z`.
Want details? I can expand this into the issue table.

5. 在 ## Details 中，用户要求提供详情时，仅在有帮助的情况下加入精简表格：
   • 优先使用 digest_rows 中的行；添加 Refs 列，并使用每行的 ref_markdown。
   • 表格应保持简短；如果摘要已涵盖相关内容，则省略信号较弱的行。
   • 使用标记、领域、类型、描述、互动和引用等精简列。
   • Description 单元格应使用简短、便于负责人阅读的表述。可参考行的 description、标题、正文摘录和近期评论，但不要机械照搬含有偶然细节的原始 GitHub issue 标题。
   • 如果没有有意义的信号，用清晰的句子说明当前平静、没有值得关注的问题。
6. 按原样使用 JSON 中的 attention_marker。普通行的值为空，高关注行的值为 🔥，极高关注行的值为 🔥🔥。具体阈值见 attention_thresholds。
7. 当某行或项目符号指向 issues 时，使用行内编号引用，例如 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 和时间窗口。默认模式下，将该说明放在详情提示之前，以便最后一行仍询问用户是否需要详情。详情优先模式下，可将其放在页脚。

反应处理

收集器使用 GitHub reactions 接口，其中包含 created_at，用于统计已获取详情的 issues 在摘要时间窗口内产生的反应。它会同时报告窗口内的反应数和当前反应总数。将当前反应总数视为持续互动，将 new_reactions / new_upvotes 视为窗口内活动。

默认情况下，收集器使用 since=<window start> 获取 issue 评论，并限制每个 issue 的评论页数。这可以避免历史过长的讨论串主导摘要运行，并将报告重点放在近期内容上。仅当完整评论历史比运行时间更重要时，才使用 --fetch-all-comments。

GitHub issue 搜索仍以 issue 的 updated_at 为种子，因此，如果反应没有更新 updated_at，则纯反应活动的 issue 可能会被遗漏。要覆盖所有仅有反应活动的情况，需要持久化快照存储，或更广泛地扫描带标签的 issues。

关注标记

收集器会根据所请求的时间窗口调整关注标记。基准为：过去 24 小时内有 5 位独立用户对应 🔥，有 10 位对应 🔥🔥；更长或更短的窗口会按比例调整阈值并向上取整。例如，一周报告的阈值为 35 和 70 次互动。独立用户指在窗口内创建了新 issue、撰写了新评论或进行了反应（包括赞成票）的用户。同一用户在同一 issue 上的多种操作只计一次。不计入机器人发布的内容和机器人反应。在正文中，应将其表述为用户互动度高，而不要提及表情符号。

时效性

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

• 在启动自动化之前刷新检出目录，例如运行 git pull --ff-only。
• 如果自动化不能安全地修改检出目录，则让它报告收集器输出中的当前 git_head，以便读者了解生成摘要时所用的技能／脚本版本。

负责人提示词示例

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

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

验证

让收集器对近期 issues 进行试运行：

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 "past week" --limit-issues 10

运行针对性的脚本测试：

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