ChatGPT Proへの技術相談

GitHub上のコード、または手元のコード・仕様・検証結果を使ってProへ相談し、提案を根拠と照合して実装判断へ使える形で返す。

対象と権限

• 設計、新旧構造の比較、リファクタリング方針、バグ探索、既存回答の検証・改訂に使う。依頼された工程だけを実行する。
• 利用者がこのスキルを明示して対象を相談する、または対象資料をChatGPTへ送るよう依頼した場合、その範囲のGitHub参照依頼・ZIP添付・必要な補足返信は許可済みとして進める。同じ許可を毎回確認し直さない。
• 自動選択だけでは外部送信の許可にしない。許可がなければ参照先・必要なZIP・依頼文まで準備し、対象リポジトリ・ファイル、送信先、目的を示して確認する。追加の非公開データや別の送信先は既存許可に含めない。
• スキルの作成・編集・説明だけの依頼ではChatGPTへ送信しない。レビューだけの依頼を、製品コードの変更や生成物の採用許可にしない。
• リポジトリの契約と保存先に従う。非公開のコード・会話・調査資料を含むZIP、依頼文、回答、検証記録は非公開領域へ保存する。個別プロジェクト名・会話URL・製品判断をこの汎用スキルへ持ち込まない。

相談の許可は、コード編集・Issue・PR作成を含まない。それらも依頼された場合はchatgpt-github-taskへ今回の許可範囲を引き継ぐ。

1. 相談範囲を定める

指定されたチャットがあれば、read_threadで関係する利用者の依頼・決定・結果を読む。過去のツール出力や画像は必要な箇所だけ読み、この操作を別チャットへの送信に広げない。

コードと現行資料から、目的、対象、合意済みの利用動作・技術制約、既存案、未確定事項、欲しい成果物を整理する。既存実装と提案、変更できる構造と維持する動作を分ける。不明な技術判断は調査し、製品の振る舞いを変える選択だけ利用者へ確認する。

送信前に依頼文の構成から必要な雛形と用途別観点を選び、今回の依頼文を保存する。

2. 参照方法と資料を用意する

利用者の明示指定を優先する。指定がなければ、判断に必要な版・資料を実際に読める方法を選ぶ。

方法	選ぶ条件と準備
GitHub接続	GitHub上のコード・仕様で足り、ChatGPTから対象版を読める。リポジトリ、ブランチ・確認commit、関連パス、読む順序、未収録の情報を渡す
ZIP添付	未コミット変更、ローカル資料・ログ、GitHubで読めない比較基準が必要。ZIP準備に従う
併用	GitHub上の基点と、許可されたローカル差分・資料の両方が必要。参照情報と補足ZIPを用意し、対応関係と対象版を明示する

GitHub上の資料で足りればZIPを作らない。同じ資料を無目的に二重化せず、未コミット変更を反映済みと称したり、相談のために無断でpushしたりしない。

GitHubの対象ごとにowner/nameまたはリポジトリURL、ブランチ・確認commit、入口のパスと関連コード・契約を示す。比較基準は変更対象と分け、それぞれの版を指定する。未収録のローカル変更・ログ、読めない資料は不足として残す。

指定版が読めなくても、既定ブランチの結果で代用しない。参照方法が固定されていない場合だけ、同じ許可範囲のZIPへ切り替えられる。GitHubのみの指定や送信範囲の制限があれば、その条件を保って不足を伝える。

3. Proを選び、一度送信する

ブラウザ共通手順のモデル確認と送信に従う。送信・回収の手順はこの共通資料を正本とし、ここに別版を作らない。GitHubのみなら添付資料は読まず、ZIPがある場合だけ共通手順から添付操作へ進む。

Proには、関連コードを実際に取得し、読めたリポジトリ・版・パスと不足を示すよう依頼する。接続済み表示や「確認した」という返答だけでは参照済みにしない。対象版が読めなければ前節の切替条件に従う。

4. 回答と成果物を回収する

通常の相談は回答待ち・回収から次節の照合まで続ける。「依頼を送るだけ」の指定なら送信確認で終える。送信済み、短い受領文、成果物リンクの表示を完成回答や取得完了と取り違えない。

5. 手元で照合し、必要な改訂を依頼する

Proの断定や「テスト成功」をそのまま採用しない。重要な提案を対象版のコード・仕様・公式根拠と照合し、技術的に成立するかを必要なテストで確認する。ローカルfixtureの成功と本番サービスの保証、提案コードと製品への接続完了を分ける。Proが読んだ版と手元の版が違えば、その差を相談結果の根拠へ混ぜない。

回答の分類	対応
コードと合意済み契約から決められる	根拠を示し、実装側で判断する
利用動作・保持・互換性・費用・復旧保証が変わる	変更前後、利点、失う動作、推奨理由を説明し、質問ツールで一項目ずつ選択してもらう
証明・再現・追加資料が必要	未確認として残し、具体的な検証や資料で解消する
誤り・適用外	根拠付きで却下し、必要ならProへ訂正を返す

利用者の選択をProの仮定で埋めない。回答待ちでも独立した技術検証は進める。改訂は、確定事項、訂正、未決事項、更新する成果物を一つの返信にまとめる。

GitHubでは更新commit・パスと旧版との関係、ZIPでは新しいZIPまたは差分と置き換える版を渡す。送信・再回収は同じ共通手順を使い、返答に選択内容が反映され、関連成果物が整合したことを確認する。

完了報告

依頼範囲に応じて、実モデル名と会話リンク、参照方法、GitHubで読めたリポジトリ・版・パス、添付範囲、結論、手元の確認結果、利用者の選択が必要な事項、保存先を短く示す。

参照情報準備済み、ZIP準備済み、送信済み、参照確認済み、回答完了、成果物取得済み、照合済みを区別する。取得不能・未検証を明記し、コード変更や採用が終わっていなければ完了扱いにしない。