Proの相談・改修とCodexのGitHub登録

Codexから依頼する改修では、Proが対象コードを読み、修正・必要検証・自己レビューを担当し、Codexが完成成果を照合して専用branchへcommit・PR作成更新する。 この分担を最初の依頼に明記する。ProのGitHub書込機能の取得を、修正開始の前提にしない。相談だけ・Issueだけの指定は、その終了点を守る。

対象と許可

• 利用者が本スキルを明示して対象を「このフローで進めて」と依頼した場合、その対象のChatGPT送信・相談・Issue作成と、軽微修正の専用branch・PR作成を含む。個別の「相談だけ」「送信だけ」「Issueだけ」を優先する。
• 利用者がProによる対象の改修とPRまでを明示した場合は、非軽微な構造・動作変更もその範囲で進める。非軽微という理由だけでIssue化へ戻さない。
• Pro本人によるcommit・PR更新までを指定されている場合は、登録担当を勝手にCodexへ変更しない。 既存の承諾を確認し、不足している場合だけ、実不足とCodexが同じ完成成果を登録する具体案を準備して担当変更を確認する。一度許可された分担を毎回確認し直さない。
• スキル名だけの呼出し、自動選択、相談依頼、雛形の存在は、無条件の外部送信・書込・製品実装許可ではない。許可済みの工程は続け、不足する範囲だけを確認する。
• スキルの編集・説明だけを頼まれた場合、そのスキルが記すProへの送信・製品改修・GitHub登録を開始しない。スキルファイル自体のcommit・PRが明示されている場合は、そのファイルを対象として扱う。
• 適用先のAGENTS.mdと資料配置規則に従う。公開差分・Issue・PR本文へ非公開資料・相談URL・個人環境の絶対パス・秘密値を転記しない。記録は既存の相談先・計画へ残す。

1. 成果・対象版・担当を定める

原依頼、目的、維持する利用動作、対象外、終了点を確認する。リポジトリのowner/name、base、確認commit、関連パス、同じ作業の既存branch・PRを特定する。事実・提案・未確認を分け、Codexで詳細設計を完成させてからProへ渡す手順にはしない。

依頼・条件	成果と担当
相談だけ	Proが根拠付きの結論・未決事項を返し、Codexが照合する。GitHubへ書き込まない
明示された改修とPR	Proが指定範囲の修正・必要検証・自己レビュー、Codexが成果照合・専用branchへのcommit・PR作成更新を行う
既定フローの軽微修正	内容と影響が明確な文言・説明・誤記を同じ分担でPRへ残す
既定フローの構造・動作変更、機能追加、実行検証を要する修正	合意した方針と受入条件を持つCodex向けIssueへ整理する。明示改修許可があれば改修を続ける
未コミット変更・ローカル再現が中心	確認済み事実・再現条件・調査対象を整理する。GitHubに存在しない情報を取得済みとせず、必要な参照方法を許可範囲で決める

変更行数だけで軽微と判定しない。軽微修正だけの許可で実行検証や範囲拡大が必要になれば、完成案と残件を分け、許可されたIssue化または範囲の確認へ進む。

GitHub上の版を基点とし、未コミット変更を反映済みと称したり、無断のpush・ZIPで補ったりしない。ZIP相談を明示された場合はchatgpt-pro-consultへ許可範囲を引き継ぐ。

Codexは依頼テンプレートとブラウザ共通手順で実モデル確認・一度の送信・回答回収を行う。Proとして直接この手順を受け取った場合は、指定版を読み、修正成果を返す。別のProへの送信やCodexチャットの起動を挟まず、GitHub登録は担当のCodexへ渡す。

2. Codexの登録経路を先に確認する

PR作成・更新を含む依頼に適用する。書込を調べる主体は登録担当のCodexであり、Proには対象版の読取と修正・検証に必要な環境を確認させる。

1. Codexの利用可能なGitHubコネクタまたはCLIで、対象repo・base・headの読取、専用branch、ファイルのcommit、PR作成更新に必要な現行機能・schema・権限を確認する。接続済み表示や過去の成功だけで代用しない。新しい権限・認証・費用を追加しない。
2. 同じ作業のbranch・commit・PRを読んで継続する。PRがなくてもbranch・commitが残っていないとは判断しない。既存PRがあれば再作成しない。
3. 書込経路を確認できたら、Proへ最初の独立した必要変更群を依頼する。完成差分と検証証拠を本文で受け取り、工程4で同じ成果を登録して読み返す。新規作業ならcodex/<作業要約>の専用branch・下書きPRへ残し、以後そのPRを更新する。

schema確認と実書込成功を分ける。最初の小さな実成果で登録・読取が済むまで、大きな成果を会話や実行環境だけへ溜めない。経路確認用のダミー変更・空commit・無関係な製品設定変更は加えない。登録機能が不足する場合は、広い改修前に具体的な不足と次の操作を整理する。

公式GitHub FAQはChatGPTのGitHubアプリを読取専用とし、編集・pushにはCodexを案内している。ProのWrite表示や一度の実成功を、返信をまたぐ書込保証へ読み替えない。明示的なPro本人の登録指定が残る場合は、現在の提供範囲と実取得機能を照合する。書込定義がない状態を検索語変更・新会話・同じ試験で反復せず、確認済み成果と不足を返す。Codex登録への変更が合意されるまではその指定を維持する。

3. Proが修正・必要検証・自己レビューを行う

ProはGitHubからAGENTS.md、必要なREADME・setup、対象コード、関連する呼出元・保存・API契約・既存試験を指定版で実読取する。読めたrepo・commit・パスを返し、接続表示や思考要約だけで参照済みにしない。

Proは許可された範囲を独立して確認できる変更群に区切り、修正・必要検証・自己レビューまで行う。通常の局所失敗は調査・修正・再確認し、依存しない作業を続ける。利用者が決める未決仕様、範囲外の変更、新権限・認証・未承認費用は推定しない。

各変更群の完成時点で、次を会話本文へ返す。

• 実読取の基点commit、対象パス、変更前のblob/SHAなど版を照合できる情報、追加・変更・削除の一覧。
• その版に適用できる完全diffまたは変更後の完全ファイル。省略・疑似コード・期限付き添付だけを成果にしない。
• 変更理由、維持した契約、自己レビュー結果、残件。
• 実行したコマンド・環境・生出力・exit code、実施済みと未実施。代替ハーネスを使った場合はその完全コード・取得版との対応・置換した依存も返す。
• 現在の実装範囲と検証結果に対応するPRタイトル・本文案。

ProはGitHubへのcommit・PR・Issue作成更新を行わない。書込定義の取得失敗で修正を止めず、必要なのは読取・修正・検証・完成成果の返却である。基点や必要ソースが読めない、試験環境が足りない場合は具体的な不足を返す。実行できなかった正式試験を代替ハーネスの成功へ換算せず、差分の返却だけで必要検証完了と称さない。

本文に収まらない成果は必要変更群ごとに返し、Codexの保存・登録確認後に次へ進む。添付を補助に使う場合も、ダウンロードだけを唯一の保存先にせず、取得不能なら本文へ展開する。参照方法・登録担当・Issue化を無断で切り替えない。

4. Codexが同じ成果を照合・commit・PR更新する

1. 保存して読む。 完成回答・diff・完全ファイル・検証原票を既存の記録先へ保存し、生成コード・ハーネスを読んでから必要な検証を行う。Proの「完了」「テスト成功」をそのまま採用しない。
2. 現版と照合する。 GitHubのbase/head・対象ファイル・blobを読み、Proの基点と返却内容が一致するか確認する。他者の差分や手元のWIPを古い全文で上書きしない。基点が動いた場合は差を同じProへ渡し、現在版に対応する成果を受け取る。
3. 不足をProへ返す。 許可範囲・維持契約・差分・実施検証と未実施を照合し、修正漏れ・回帰・説明不整合は具体的根拠とともに同じ会話へまとめて訂正依頼する。必要な独立検証はCodexでも行い、実施者を分ける。Codexが別設計・別実装へ置き換えたり、意味を変える修正を黙って加えたりしない。
4. 確認した成果を登録する。 現行ツールのschemaに従いref・SHAを指定して専用branchへcommitする。PRがなければ下書きPRを作り、あれば同じPRを更新する。途中なら完成範囲・残件・未実施検証を本文へ残す。baseへの直接commit・自動mergeは行わない。
5. 登録結果を読み返す。 PR URL・repo・base/head・変更commitと親・実差分・対象blob、PR本文をGitHubから読み、返却成果と一致することを確認する。作成・更新・確認したPRをattach_artifactで現在のCodexチャットへ添付する。Proが作成した成果をCodexが登録したと報告し、作者・登録者を偽装しない。
6. 次の変更群へ引き継ぐ。 登録後のhead・変更パスと検証結果、残件を同じProへ渡し、次の必要変更群を依頼する。古い基点へ戻さず、最後の登録済みcommitから継続する。

必要検証が環境不足で未実施なら、Proの環境とコマンドの実結果から不足を調べ、許可範囲の具体策を渡す。未実施はPR本文と残工程に保持する。途中成果の保存を、改修全体や正式検証の完了と取り違えない。

5. 合意した内容をIssueにする

Issue化が許可された工程だけに使う。Proが目的、合意事項、対象コード・確認commit、変更範囲・対象外、受入条件、検証方法、未決事項を、対象repoのIssueテンプレートに合わせて確定本文へ整理する。未決仕様を決定済みにしない。

Codexが関連Issueを読み、同じ作業なら既存Issueを更新し、なければ作成する。作成・更新後は実本文・repo・URLを読む。assignee・label・milestoneは指定や既存運用がある場合だけ設定する。公開範囲を守り、会話リンクだけに依存しない本文へする。Issue作成を実装・検証の完了に読み替えない。

6. 不足・結果不明と終了を扱う

Proのソース読取・修正・検証・返却の不足と、Codexの定義未取得・書込拒否・CLI接続失敗・登録結果不明を分ける。実行主体、試した入力、返却・生出力、具体的な不足を調べてから次策を判断し、未調査で利用者へ担当変更の二択を返さない。

登録結果が不明なら同じrepo・branch・PRの実成果を先に照会し、重複commit・PRを作らない。登録できなければ、最後の登録済みcommitと未登録の完成成果を保存し、不足する操作を示す。同じ検索・DNS失敗・再ログイン・再インストールを根拠なく繰り返さず、ZIP・Issue・新会話・別担当へ自動変更しない。普通の復旧で解けない不足についてだけ、準備した具体案と必要な判断を示す。

許可された全範囲を変更・実施検証・未実施・残件へ対応付け、部分PRや経路確認だけへ終了点を縮めない。回答待ち・回収・再送はブラウザ共通手順に従い、変更のない待機は静かにする。

報告は実モデル・会話リンク、成果作成者と登録担当、PRまたはIssue URL、実基点・base/head・commit、確認済みの改修と検証、未実施・残件、保存先を短く示す。相談結果・完成差分・登録済み・検証済み・merge済みを区別する。PR登録はmain採用や製品全体の完了ではない。

Issue化後は既定で終了する。Codexでの実装まで明示されている場合だけ現行Issueと手元のコードを照合して引き継ぐ。新規Codexチャットは起動の明示依頼がある場合だけ作り、Proの返答を新チャット・ワーカー委任の許可にしない。