このページでわかること
Issueの読み方、作業範囲、branch作成、実装、確認、PR、報告までの流れがわかります。
結論
CodexにGitHub実務を任せる時は、対象repo、branch、差分、Secrets、CI、PR本文を分けて確認します。main直push、危険操作、テスト無効化、private repoなら安全という考え方は避けます。
対象読者
CodexでGitHubのIssue、PR、レビュー、CI、branch、private repo、READMEやrelease noteを扱いたい人向けです。
Codexに任せやすいこと
Issue要約、不明点整理、作業範囲表、PR本文下書き、確認結果の整理。
人間が確認すべきこと
Issueの意図を変えていないか、無関係な修正を混ぜていないか、Secretsが差分にないか。
GitHub作業での注意点
Issueを読んで、実装範囲を絞り、branchで作業し、PR本文に目的、変更内容、確認結果、未確認点を書きます。
やってはいけないこと
危険コマンド、force pushの安易な推奨、テスト無効化、Secretsやtokenのログ出力、社内コードや顧客情報の入力推奨は避けます。
STOP条件
Issueの意図が不明、設計変更が必要、秘密情報が必要、無関係な大修正が必要な場合。
作業の記録は、後から読む人のために書く
やることの記録も、変更の説明も、数週間後に読み返すのは自分です。そのときに要るのは、何をしたかよりなぜそうしたかです。
| やることの記録に書く | いま何が起きているか／どうなれば終わりか／触らない範囲 |
|---|---|
| 変更の説明に書く | 何を変えたか／なぜ変えたか／確認した方法／確認していないこと |
「確認していないこと」を書くのが要点です。全部確かめたように見える説明は、読む側が確認を省く原因になります。手が回らなかった範囲を明示しておけば、そこを見てもらえます。
1回の変更を小さく保つ
まとめて出したほうが速いように見えますが、読む側の負担が跳ね上がり、結局は通すのが遅くなります。そして問題が起きたときに、戻す範囲が大きくなります。
- 目的ごとに分ける。「文章の修正」と「見た目の調整」を混ぜない
- 共通部分の変更は単独にする。影響が全ページに及ぶので、それだけで戻せる形にします
- ついでの整理を混ぜない。気づいた点は記録に残し、別の作業として扱います
混ぜてしまうと、良い変更と悪い変更が同じ塊になり、片方だけ戻せません。「ついでに直した」部分が原因だった場合、本命ごと巻き戻すことになります。
そして出す前に、入っているファイルの一覧を見てください。作業中に作った一時ファイルや出力データが混ざっていると、後から取り除いても記録には残ります。
FAQ
Issueからすぐ実装してよいですか？
まず目的、範囲、不明点を整理します。
Issueにない修正も入れてよいですか？
混ぜない方が安全です。別Issueや別PRに分けます。
PR本文には何を書きますか？
目的、変更内容、確認結果、未確認点、関連Issueを書きます。
不明点がある場合は？
勝手に進めず、質問やSTOP条件として整理します。