Codex Issue Digest

目的

リクエストされた機能領域ラベルに対して、openai/codex のIssueをデフォルトで過去24時間分、見出しファーストでインサイト豊富なダイジェストを生成します。ユーザーが「過去1週間」や「48時間」など異なる期間を指定した場合は、その期間を優先します。デフォルトではサマリーのみを返し、詳細はリクエストがあった場合のみ含めます。

現在 bug または enhancement のラベルがあり、かつ少なくとも1つのリクエストされたオーナーラベルが付与されているIssueのみを含めます。ユーザーが「全領域」や「全ラベル」を指定した場合は、すべてのラベルの bug/enhancement Issueを収集します。

入力

機能領域ラベル（例: tui exec）
all areas / all labels：現在の全機能ラベルをスキャン
オプションのリポジトリ指定、デフォルトは openai/codex
オプションの時間枠、デフォルトは過去24時間。例：48h、7d、1w、past week

ワークフロー

現在の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 を使用します。

JSONを真実のソースとして使用します。これには、新しいIssue、新しいIssueコメント、新しいリアクション/upvote、現在のラベル、現在のリアクション数、モデル読み取り可能な summary_inputs、および詳細な digest_rows が含まれます。
ユーザーのリクエストに基づいて出力モードを選択します：
- デフォルトモード：レポートを ## Summary で開始し、## Details は出力しません。
- 詳細先出しモード：ユーザーが詳細、テーブル、完全なダイジェスト、「詳細を含める」などを要求した場合、## Summary で開始し、続けて ## Details を含めます。
- フォローアップ詳細モード：サマリーのみのダイジェストの後にユーザーがさらに詳細を要求した場合、既存のコレクターJSONが利用可能であれば ## Details を生成し、そうでなければコレクターを再実行します。
## Summary では、見出しファーストのエグゼクティブサマリーを記述します：
- ## Summary の下の最初の空白でない行は、箇条書きではなく、1行の見出しまたは判断でなければなりません。読者がそこで止めても役立つようにします。
- 静かな日は、正確に No major issues reported by users. を使用します。これは、注目すべき行がなく、新たに繰り返されるテーマもなく、オーナーのアクションが必要なものがない場合に使用します。
- ユーザーが注目すべきIssueを表面化させている場合は、見出しに件数やテーマを明記します。例：Two issues are being surfaced by users:。
- アクティブな見出しの直下には、重要度順に注意を引くIssueまたはテーマのみをリストします。各行は、その行の attention_marker が存在する場合はそれで開始し、次に簡潔なオーナー読み取り可能な説明とインラインIssue参照を続けます。
- 🔥🔥 を見出しに値するものとして、🔥 を注目すべきものとして扱います。自分で炎の絵文字を追加せず、行の attention_marker のみをコピーします。
- 見出しの後の追加のサマリー詳細は、決定に関連する注意点、繰り返されるテーマ、またはオーナーアクションを追加する場合にのみ、1～3行の簡潔な行に抑えます。
- ## Summary には、ルーチンのカウント、広範な統計、または低シグナルのテーブルサマリーを含めません。ただし、それらが見出しを変更する場合は除きます。メタデータとオプションのカウントは ## Details またはフッターに配置します。
- デフォルトモードでは、Want details? I can expand this into the issue table. のような簡潔なプロンプトでレポートを終了します。これはサマリー見出しとは別に保ち、見出しをクリーンに保ちます。
- summary_inputs からテーマを自分でクラスタリングして名前を付けます。コレクターは意図的にIssueカテゴリをハードコードしません。
- クラスタは、Issueが真に同じ製品の問題を共有している場合にのみ使用します。複数のIssueが単に広いプラットフォームやラベルを共有している場合は、個別に説明します。
- 個々のIssueが詳細テーブルのカットオフを下回っているからといって、繰り返されるテーマを省略しないでください。類似した複数の報告は、繰り返される顧客の懸念として指摘する必要があります。
- 単一Issueの行については、クラスタと呼ぶ代わりに懸念事項を直接要約します。
- 各関連行の ref_markdown からのインライン番号付きIssueリンクを使用します。
- 静かなサマリーの例：

## 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.

## Details では、詳細がリクエストされた場合にのみ、有用な場合にコンパクトなテーブルを含めます：
- digest_rows の行を優先します。各行の ref_markdown を使用して Refs 列を含めます。
- テーブルは短く保ちます。サマリーで既にカバーされている低シグナルの行は省略します。
- マーカー、領域、タイプ、説明、インタラクション、参照などのコンパクトな列を使用します。
- Description セルは、オーナーが読める短いフレーズにします。行の description、タイトル、本文の抜粋、最近のコメントを使用しますが、付随的な詳細が含まれている生のGitHub Issueタイトルを機械的にコピーしないでください。
- 意味のあるシグナルがない場合は、明確な静か/懸念なしの文を記述します。
JSONの attention_marker をそのまま使用します。通常の行では空、注目すべき行では 🔥、非常に注目度の高い行では 🔥🔥 です。実際のカットオフは attention_thresholds にあります。
行や箇条書きがIssueを指している場合、インライン番号付き参照を使用します。例：Compaction bugs [1](https://github.com/openai/codex/issues/123), [2](https://github.com/openai/codex/issues/456)。別の脚注セクションは追加しないでください。
interactions には Interactions というラベルを付けます。これは、リクエストされた時間枠内に新しいIssueを作成したり、新しいコメントを追加したり、リアクションを行ったりした一意の人間のGitHubユーザーをカウントします。同じユーザーが同じIssueに対して複数の投稿/リアクションを行った場合は、1回としてカウントします。
コレクターの script_version、リポジトリチェックアウトの git_head、および時間枠を1つのコンパクトなソース行で言及します。デフォルトモードでは、これを詳細プロンプトの前に配置し、最終行がユーザーに詳細を望むかどうかを尋ねるようにします。詳細先出しモードでは、これをフッターにできます。

リアクションの処理

コレクターは、GitHubリアクションエンドポイント（created_at を含む）を使用して、ハイドレートされたIssueに対してダイジェスト期間中に作成されたリアクションをカウントします。期間内のリアクション数と現在のリアクション総数の両方を報告します。現在のリアクション総数は継続的なエンゲージメントとして扱い、new_reactions / new_upvotes は期間内のアクティビティとして扱います。

デフォルトでは、コレクターは since=<ウィンドウ開始> でIssueコメントを取得し、Issueごとのコメントページ数を制限します。これにより、非常に長い履歴スレッドがダイジェスト実行を支配するのを防ぎ、レポートを最近の投稿に集中させます。--fetch-all-comments は、網羅的なコメント履歴がランタイムよりも重要な場合にのみ使用します。

GitHub Issue検索は依然としてIssueの updated_at でシードされるため、リアクションのみのIssueは、リアクションが updated_at を更新しない場合に見落とされる可能性があります。すべてのリアクションのみのケースをカバーするには、永続化されたスナップショットストアまたはラベル付きIssueのより広範なスキャンが必要になります。

注目マーカー

コレクターは、リクエストされた時間枠に応じて注目マーカーをスケーリングします。基準は、24時間で一意の人間ユーザー5人で 🔥、10人で 🔥🔥 です。それより長いまたは短い時間枠では、これらのカットオフを線形にスケーリングし、切り上げます。たとえば、1週間のレポートでは35と70のインタラクションを使用します。一意の人間ユーザーとは、期間中に新しいIssueを作成したり、新しいコメントを作成したり、リアクション（upvoteを含む）を行ったユーザーです。同じユーザーが同じIssueに対して複数のアクションを行った場合は、1回としてカウントします。ボットの投稿とボットのリアクションは除外されます。散文では、絵文字に名前を付けるのではなく、高いユーザーインタラクションとして説明します。

鮮度

自動化は、このスキルを含むリポジトリチェックアウトから実行する必要があります。共有の日次使用では、次のパターンのいずれかを推奨します。

自動化の開始前にリフレッシュされたチェックアウトで自動化を実行します。たとえば、git pull --ff-only を使用します。
自動化がチェックアウトを安全に変更できない場合は、コレクター出力から現在の git_head を報告し、どのスキル/スクリプトバージョンがダイジェストを生成したかを読者が知ることができるようにします。

サンプルオーナープロンプト

$codex-issue-digest を使用して、ラベル tui と exec の過去24時間のCodex Issueダイジェストを実行してください。

$codex-issue-digest を使用して、全領域の過去1週間のCodex Issueダイジェストを実行してください。

検証

最近の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

codex-issue-digest