Codex作業をGitHub Issueで管理するには｜作業依頼・PR・報告書の流れ

まず一言でいうと

Issue管理の親ハブです。GitHub Issueは、Codexに頼む作業の目的、対象、やること、やらないこと、停止条件、確認結果を残す場所として使えます。

Issueには、目的、対象URL、対象ファイル、やること、やらないこと、停止条件、確認項目、報告形式を書きます。秘密情報の実値は書かず、必要なら一般化した表現に置き換えます。

目的:
対象URL:
対象ファイル:
やること:
やらないこと:
停止条件:
確認項目:
報告形式:
触らないファイル:
秘密情報チェック:

CodexにはIssueの内容をもとに、対象範囲内の調査、実装、確認、報告を依頼します。DB、cron、.htaccess、認証情報、Search Console確認タグ、AdSenseコードが必要になりそうな時は停止条件として扱います。

Codex github issueやCodex issueの相談では、Issue本文をそのまま実装依頼にせず、目的、再現手順、期待結果、実際の結果、対象URL、対象ファイル、触らない範囲を分けて整理します。ラベルやコメントは補助情報として扱い、不明点がある場合は勝手に実装へ進めない形にします。

このIssueを読み、変更対象ファイルと必要な修正だけを整理してください。
実装前に、触るファイル、触らないファイル、確認項目を報告してください。
Issueに書かれていない範囲や秘密情報には触れないでください。

GitHub側の全体像は CodexとGitHub連携、安全面は Codex安全運用、戻す前提はロールバック確認もあわせて確認します。

Issue本文をそのままCodexに渡してもよいですか？

そのまま渡すより、目的、再現手順、期待結果、対象ファイル、触らない範囲を整理してから渡す方が安全です。

Issueに書かれていない部分もCodexに直してもらうべきですか？

基本はIssueの範囲に限定します。関連しそうでも、別ファイルや別機能に広げる場合は、先に確認した方が安全です。

Issueを作ればCodex作業は安全になりますか？

Issueは作業範囲を整理する助けになりますが、それだけで安全になるわけではありません。PR差分、報告書、秘密情報、停止条件を確認します。

Issueに秘密情報を書いてよいですか？

書かないのが基本です。APIキー、パスワード、トークン、顧客情報、サーバー情報は伏せるか一般化します。

IssueとPRはどう違いますか？

Issueは作業依頼やタスク管理、PRは実際の変更差分を確認する場所として分けると分かりやすいです。

未完了タスクはどう扱いますか？

報告書からIssueへ戻し、次にやること、止めた理由、確認待ち項目として残します。

GitHub Issueは作業依頼の置き場として便利ですが、Issue本文に秘密情報を書かないことが前提です。Codexへ渡す時は、目的、対象URL、触ってよい範囲、停止条件、PR確認、Secrets確認を分けます。

PR、review、CI、branch、private repo、Issue、README、release noteへつなぐページです。