codex-issue-digest

Codex イシュー概要

目的

デフォルトでは過去24時間を対象に、指定された機能領域ラベルが付いた openai/codex のイシューを、要点を重視した見出し先行の概要にまとめます。ユーザーが「過去1週間」や「48時間」など別の期間を指定した場合は、その期間を適用します。デフォルトでは概要のみを返し、詳細は要求された場合にのみ含めます。

現在 bug または enhancement が付いており、さらに指定された担当領域ラベルが少なくとも1つ付いているイシューのみを含めます。ユーザーがすべての領域またはすべてのラベルを指定した場合は、すべてのラベルにわたって 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 の下にある最初の空行でない行は、箇条書きではなく、1行の見出しまたは判断にします。その行だけを読んでも役立つ内容にしてください。
   • 静かな日には、次の文を正確に使うことを優先します：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の行を優先し、各行の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への複数の投稿やリアクションは1人として数えます。
9. 収集ツールのscript_version、リポジトリチェックアウトのgit_head、期間を、簡潔なソース行にまとめて記載します。デフォルトモードでは、最後の行で引き続き詳細を希望するかどうかを尋ねるよう、詳細の質問より前に記載します。詳細先行モードでは、フッターに記載できます。

リアクションの処理

収集ツールは、created_atを含むGitHubのリアクションエンドポイントを使用して、詳細情報を取得したissueについて、ダイジェスト期間中に作成されたリアクションを数えます。期間内のリアクション数と現在のリアクション総数の両方を報告します。現在のリアクション総数は継続的な反応として扱い、new_reactions／new_upvotesは期間内のアクティビティとして扱います。

デフォルトでは、収集ツールはsince=<window start>を指定してissueのコメントを取得し、issueごとにコメントページ数の上限を設けます。これにより、非常に長い過去のスレッドがダイジェストの実行を過度に左右するのを防ぎ、最近の投稿に重点を置けます。実行時間よりもコメント履歴を網羅的に取得することが重要な場合に限り、--fetch-all-commentsを使用してください。

GitHub issue検索では引き続きissueのupdated_atを基準に検索を開始するため、リアクションによってupdated_atが更新されない場合、リアクションのみのissueが見落とされることがあります。リアクションのみのケースをすべて網羅するには、永続化されたスナップショットストアか、ラベル付きissueのより広範なスキャンが必要です。

注目度マーカー

収集ツールは、指定された期間に応じて注目度マーカーを調整します。24時間の場合、🔥の基準は一意のユーザー5人、🔥🔥の基準は一意のユーザー10人です。期間が長くなる場合も短くなる場合も、しきい値は比例して調整され、端数は切り上げられます。たとえば、1週間のレポートでは、インタラクション数の基準は35と70になります。一意のユーザーとは、期間中に新しいissueを作成したか、新しいコメントを投稿したか、リアクションしたユーザーを指し、賛成票も含みます。同じユーザーによる同一issueへの複数のアクションは1人として数えます。ボットによる投稿やリアクションは除外されます。文章では絵文字の名前を挙げず、ユーザーのインタラクションが多いこととして説明してください。

最新性

自動化は、このスキルを含むリポジトリのチェックアウトから実行してください。日々の共有利用では、次のいずれかの方法を推奨します。

• 自動化の開始前に更新するチェックアウト（例：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.

検証

最近のissueを対象に、収集ツールをドライランします。

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