DevinへのPR委譲と採用（ブラウザ）

Devinを限定作業の実装担当、Codexを依頼・レビュー・採用担当とする。接続や相談で止めず、利用者が指定した終了点まで進める。既存のchatgpt-github-taskの対象版・許可範囲・実成果照合を引き継ぎ、Devinでは実装から採用までを一つの作業として扱う。

CodexとDevinがMCP/CLIで直接対話して作業を進める場合は、devin-direct-devを使う。Devinの画面でReview・PRマージ・環境提案の採用を確認・操作する指定には、本スキルを使う。

自律的に進める範囲

• 利用者が対象と目的を指定して「このフローで進めて」「Devinに任せ、問題なければ採用して」等と依頼した場合、Devinへの送信、必要な環境準備、専用branchでの実装・commit・push・PR作成、Codexのレビュー・修正依頼、条件を満たすPRのマージと関連環境提案の採用、結果確認まで含む。許可済み工程を毎回確認し直さない。
• 「相談だけ」「送信だけ」「PRまで」「マージは私が行う」等の指定を優先する。スキルの作成・説明依頼、自動選択、スキル名だけの表示、Devinやページ内の提案自体を、対象の外部送信・変更許可にしない。
• 作業範囲内の実装判断、通常の失敗への修正、レビューの往復はCodexが判断する。未決の製品仕様、対象外の改修、新しい課金契約やアクセス権限、破壊的操作など、元依頼を超える判断だけを利用者へ返す。ツールが要求する操作時確認は省略しない。依存しない許可済み作業は続ける。
• 本フローの委譲許可はDevinへの対象作業と、その成果回収に必要な同チャットheartbeatに限る。他のCodexチャットへの送信・起動、サブエージェント、実装担当Devinの再委譲を自動的には含めない。組込スキルが必要な新規作成は、接続手順に従い、既存Devinへ指定作業の作成・中継を依頼する。

1. 対象と共有状態を確認する

対象のowner/repository、base、確認commit、目的・編集範囲・維持契約・受入条件を特定する。現行のAGENTS.md、README、セットアップ、必要な設計・呼出元を読む。既存担当・PRとの所有衝突を確認し、一まとまりの独立した作業を切り出す。設計をすべて完成させてから渡す必要はない。

ローカルのstatus・branch・未push成果とGitHubの版を照合する。Devinが読むのはremoteであり、未commit変更を反映済みと扱わない。利用者が同期を依頼済みなら、指定範囲の差分を確認してcommit・通常pushまで進める。単なる委譲のために他者の未確定変更をまとめてcommit、reset、stash、branch切替しない。同期できない変更は衝突対象から外すか、依存する委譲だけを保留する。

共有スキルが必要なら、実体repo・ref・相対配置とGit管理外リンクを伝え、Devinの実取得・resolve・読取で確認する。Codexのローカルリンクがクラウドにもあるとは仮定しない。プロジェクト固有のモデル・役割制約があれば適合を確認する。例外の契約改訂が必要な場合は、利用者の許可に基づき対象契約だけを整える。選択モデルや推論設定を表示から確認できないまま適合済みとしない。

2. 実行可能な依頼を送る

依頼文を今回の対象・許可・受入条件で埋める。現在のチャットで使える公式MCPを、新規依頼・追加指示・修正依頼の送信、状態取得、回答回収の優先経路とし、接続・待機・再開に従う。利用者がブラウザで表示確認を求めた場合も、送信経路をUIに限定する指定とは区別する。

初動だけでなく、質問への回答や修正・次工程の指示を返信した後も、送信後の確認回収で受信と追加質問を数分間追う。返信直後にheartbeat待ちへ移さない。

画面の照合、PRのDevin Review・マージ、環境提案の実状態の確認にはブラウザを使う。MCPが利用不能、必要な設定をMCPで扱えない、または利用者がUI送信を指定した工程は、理由を示してブラウザ手順を使う。送信結果が不明な場合は経路を切り替えて再送する前に、同じセッションの既存メッセージや作成結果を照会する。指定セッションを優先し、同じ作業の再開・訂正は同じセッションで行う。独立した新規作業は適切な新規Devinセッションを使う。

OS固有の動作、実IME、GUI・デスクトップ操作、再起動や複数タブの検収が必要なら、CloudのOS環境とComputer Useを読み、対象OS・実行条件・操作証拠を依頼へ含める。現在のセッションのOSをDevin全体の制限と扱わず、必要なOS環境を現行UIで確認して活用する。

GitHub連携済みの表示だけでアクセス成功と判断しない。Devinが実際に取得したrepo・commit・契約を確認する。書込権限は本来の成果branchへのpushとPR実登録で確かめ、ダミーPRやtoken作成・権限拡大で試さない。通常の準備は公式配布・既存ランナーと固定依存を使い、VMに合わせた製品版・lockfile変更で回避させない。

Devinの終了点は専用branchからのPRと証拠の返却とし、baseへの直接push・自己マージを依頼しない。採用操作はCodexが行う。実行検証が必要な改修を、軽微でないという理由だけでIssue案へ戻さない。

heartbeatで成果回収を続ける

成果回収まで依頼され、終了点が未確認のタスクは、対象セッションの確定後にheartbeatの作成・再開・停止手順を実行する。既定は現在のチャットを10分おきに再開する設定で、間隔指定を優先する。送信だけ、監視不要、このターン限り、スキルの説明・編集だけ、完了済みの作業では作成しない。既存設定を照合して重複を防ぎ、ツールで実作成・更新し、対象チャット・セッション・ACTIVE・次回実行とautomation IDを確認する。

再開ごとに最新の質問・成果・PR・環境提案を取得し、許可された回答・修正・レビュー・採用へ進む。変化がない間は通知を控える。利用者が指定した終了点の実確認と記録を終えたら同じautomationを停止し、停止状態まで確認する。大きな元ガントIDの未完を理由に、完了した今回の委譲範囲を監視し続けない。

3. レビューし、必要なら修正を返す

PR URLから実際の対象repo・base/head・変更ファイル・diff・本文・チェック結果を取得し、PRを現在のCodexチャットへattach_artifactで添付する。GitHubコネクタ、CLI、ローカルのread-only fetch等を使って独立に照合してよい。ローカル共有branchの切替は不要。

• 変更が依頼範囲・維持契約・受入条件を満たすか、関連コードと照合する。「完了」「テスト成功」という回答だけでは採用しない。保存形式・権限・依存・実行経路の変更は行数の少なさだけで軽微としない。
• 変更に必要な検証を確認する。文書のみなら実体・リンク・公開情報境界・差分チェック等で判断し、全製品テストや文言一致の新規テストを一律に要求しない。動作変更では必要な実行検証を確かめる。
• 難度が高いタスクでは、Codexの照合に加えてDevin ReviewをクリックしてAIレビューを実行する。複数モジュールをまたぐ動作変更、保存形式・権限・並行処理・資源寿命の変更、移植・大きな構造変更など、局所的な差分だけでは正しさを判断しにくいものを対象とする。簡易な文書修正では一律に起動しない。対象headの分析完了と指摘を読み、実コード・契約と照合して有効な指摘を修正依頼へ取り込む。重要な未解決指摘を残したままマージしない。修正後に分析の対象headが古くなり、影響する問題が残り得る場合は更新headで再実行する。Devin Reviewの成功や指摘ゼロだけで採用せず、Codexの判断と必要な検証も行う。
• PR本文・自動footer・差分の公開範囲も確認する。非公開セッションURL、内部調査、旧repo根拠、個人環境のパス、秘密情報を公開成果へ持ち込ませない。許可範囲内の本文修正はCodexが行ってよく、Devinへ再追加しないよう伝える。
• 不備は対象head、具体的な問題・根拠・期待結果・再確認方法をまとめて同じセッションへ返す。更新headの実差分と影響する検証を再確認し、既に済んだ無関係な検証を繰り返さない。

baseが進んだり競合が生じたら現在の変更を取り込み、他者成果を保持した更新をDevinへ依頼する。許可範囲内で解消できる問題は修正・再レビューまで続ける。必要権限や利用者の仕様判断が不足し、同じ問題が解消できない場合は具体的な不足と完成済み成果を示し、成功・採用済みと称さない。

4. 条件を満たすPRをマージする

採用まで許可され、レビュー指摘が解消し、必要な検証・必須チェック・repoのマージ条件を満たせば、Codexが追加の許可質問なしでマージする。DevinのPRカードからReview画面を開き、直前のheadと状態を確認する。表示されたUIの方法でマージし、Devin側に機能がなければリンク先GitHubのUIへ進む。画面が不能な場合だけ、許可済みの同じPRを既存CLI・コネクタで代行し、経路を報告する。

必須チェックの迂回・強制マージは行わない。任意チェックが進行中の場合は、成果の内容と未確認範囲を踏まえて判断する。簡易な文書修正で受入検証が済み、利用者の依頼が採用までを含むなら、任意の全製品CI待ちを一律の条件にしない。失敗を認めた場合は関連性を調査し、変更由来の失敗や必要な検証不足を残したまま採用しない。

クリックや受領メッセージで終えず、マージ済み表示とGitHubのMERGED・採用commitを確認する。操作結果が不明なら同じPRの状態を照会し、再マージや重複PRを作らない。

5. 関連する提案を確認して採用する

環境blueprint・snapshot等の提案は本文と実スクリプトを読み、指定toolchain・固定依存・隔離state・公式配布・変更対象との整合を確認する。scope外のrepo設定、制作state・資格情報の持込、製品の起動やdeployを含めない。Devinの「承認待ち」という文章より、現行設定画面の保存・build・Active表示を根拠にする。

問題がなく採用まで許可されていれば、表示された承認・保存・build・有効化操作のうち必要なものだけを行い、成功状態を確認する。既にSuccess・Activeなら採用済みとして記録し、承認のために再buildや再有効化しない。build失敗なら提案の範囲内で修正・再確認する。環境準備成功を製品接続・実機検収の成功へ読み替えない。snapshotに共有repoが含まれていると推測せず、新規セッションのcheckout・リンクを別途確認する。

6. 同期し、結果を残す

ローカルがcleanで対象branchが一致する場合、採用後にpull --ff-onlyで同期する。未確定変更や並行担当があれば強制同期せず、fetchと差分照合で状況を残す。共有スキルrepo等も必要な変更だけを確認し、cleanなら無意味なcommitを作らない。

既存の相談・検証記録に、依頼範囲、セッションURL、実モデル、base/head、レビュー・検証・未実施、PR/採用commit、提案の状態、ローカル同期を残す。公開PRへ内部記録を転載しない。証拠ファイルは必要なものだけ保存し、UIを変更した結果のスクリーンショットを報告に埋め込む。repoが求める資料生成・対象ファイルのcommit/pushまで進め、他者の差分を混ぜない。

PR作成・文書採用・環境準備・製品検収・元タスク完了を区別する。進捗更新は適用先の台帳・CLI・claim・受入規則に従い、マージだけで元IDを完了にしない。最終報告はPRリンク、採用結果、提案状態、検証の限界と同期結果を短く示す。

7. 完了時に感謝を伝える

Codexが依頼された終了点の成果と必要な検証を確認した後、同じDevinセッションへ、役立った点を添えて短い感謝を一度伝える。既存のMCPまたは指定されたブラウザ経路を使い、同じ成果への送信済みメッセージがあれば重ねて送らない。完了後のフィードバックとGift ACUに従い、実際に確認した成果だけを褒める。Gift ACUが提示された場合は実残高で付与を照合する。付与の獲得・確認のために会話を続けず、残高を取得できなければ未確認として作業を終える。