菜单
Codex CLIと相談するスキル。 ユーザーが「codexと相談して」「codexに聞いて」「codexにレビューしてもらって」と言った時に使用する。 現在の会話コンテキストに基づいてCodex CLIにプロンプトを送り、結果を要約して報告する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
リポジトリのセキュリティ調査を領域ごとに進める。 調査対象リストと観点リストに基づき、未調査の領域を選んで調査し、レポートを出力する。 複数sessionにまたがる長期作業を想定し、現状を確認して続きの作業を行う。
PRのレビュー報告書を作成する。bugや脆弱性の調査だけでなく、exportされた対話コンテキスト・PR概要欄・実装されたコードの整合性を確認し、実装者の正気を疑う。 ユーザーが「PRのレビュー報告書を書いて」「対話コンテキストと共にコードレビューして」「このPRの正気を疑って」と言った時に使用する。
対話コンテキストをexportする。 会話で共有された目的・意図・設計判断・制約条件を `.dev/contexts/` ディレクトリに書き出し、PRが存在する場合はPRコメントにも投稿する。次の作業者（レビュワー、別セッションのAI、バグハンティングのAIなど）に引き継ぐ。 ユーザーが「コンテキストを書き出して」「対話コンテキストをexport」「会話した内容を.devに保存して」と言った時に使用する。
対話コンテキストをimportする。 `.dev/contexts/` ディレクトリに保存された過去の対話コンテキストを読み込み、開発の継続やレビューに活用する。 ユーザーが「コンテキストを読み込んで」「対話コンテキストをimport」「.devのコンテキストを読んで」と言った時に使用する。
定石外発想で実装をシンプルにする。現状の発展型ではなく、実装の裏にある暗黙の前提条件を1つずつ外し、よりシンプルな別解がないか検討する。 ユーザーが「定石外発想で」「前提を疑って」「もっとシンプルにできないか」と言った時に使用する。
Agentツール（subagent）と相談するスキル。 ユーザーが「subagentと相談して」「subagentに聞いて」「subagentにレビューしてもらって」と言った時に使用する。 現在の会話コンテキストに基づいてsubagentにプロンプトを送り、結果を要約して報告する。
| name | codex-consultation |
| description | Codex CLIと相談するスキル。 ユーザーが「codexと相談して」「codexに聞いて」「codexにレビューしてもらって」と言った時に使用する。 現在の会話コンテキストに基づいてCodex CLIにプロンプトを送り、結果を要約して報告する。 |
相談先Agent（Codex CLI / OpenAI）にセカンドオピニオンを求め、その結果を要約してユーザーに報告する。 ユーザーはcodexの生出力を直接見る必要はない。相談元Agentがcodexの回答を咀嚼し、自分の見解と照らし合わせて報告する。
本手順には3者が登場する:
ユーザーへの報告時、見出しに自分のAgent名を使うこと（例: 「Claude Codeの見解」「Clineの見解」等）。
Bashツールで以下を実行する:
command -v codex
codexが見つからない場合は、ユーザーに「Codex CLIがインストールされていません」と報告して終了する。 それ以上の作業は行わない。
ユーザーが相談の深さを明示していない場合（「全力で」「深く」「よく」「軽く」等の指定がない場合）、 AskUserQuestionツールで以下の3択を提示する:
| 選択肢 | 往復回数 | 相談元Agentの仮見解 | 漏れ抜けの追求度 |
|---|---|---|---|
| よく相談する（推奨） | 必要に応じて2往復 | 相談元Agentが判断 | 漏れ抜けを確認して報告 |
| 全力で深く相談する | 2往復を原則実施（明らかに不要な場合のみスキップ） | 必ず含め、Codexに反論を促す | 積極的に反論・補完・追加追求 |
| 軽く相談する | 1往復のみ | 相談元Agentが判断 | Codexの指摘を整理して報告 |
ユーザーが明示的に深さを指定している場合はこの確認を省略し、指定に従う。
codexに渡すプロンプトを相談元Agentが設計する。以下の指針に従う:
「このリポジトリの未commitの変更をレビューしてください。コードの品質、設計の妥当性、潜在的なバグ、改善点を指摘してください。」
「以下の設計について意見をください。[設計の要約]。代替案やトレードオフがあれば提案してください。」
「[タスクの要約]を実装したい。このリポジトリのコードベースを踏まえて、最適な実装方針を提案してください。」
なお相談元Agent（[自分のAgent名]）は現時点で以下のように考えている:
- [仮見解]
この見解の漏れ・誤りも含めて、幅広くレビューしてほしい。
指定した観点以外にも気になる点があれば積極的に報告してほしい。
指定された観点はあくまで出発点であり、制約ではない。 リポジトリを自分で探索して気になる点があれば積極的に報告してほしい、という旨を必ずプロンプトに含める。
Bashツールで以下の形式で実行する:
codex exec --ephemeral -s workspace-write -c sandbox_workspace_write.network_access=true "ここにプロンプトを入れる" < /dev/null
--ephemeral は必須。セッションを保存しない-s workspace-write -c sandbox_workspace_write.network_access=true は必須。デフォルトではサンドボックスがネットワークアクセスをブロックするため、ghやcurlなどの外部通信コマンドが失敗する< /dev/null は必須。プロンプトを引数で渡していても、stdinがpipe状態だとcodexは追加入力を <stdin> ブロックとして読みに行きEOFまで待つため、明示的に閉じないとhangするcodexの実行には時間がかかる場合がある。Bashツールのtimeoutを900000（15分）に設定する。
「全力」モードでは、1往復目の結果を受け取った後、2往復目を原則実施する。明らかに追加の深掘りが不要な場合（1往復目で十分網羅的な回答が得られた場合）のみスキップする。
「よく」モードでは、1往復目の結果を受け取った後、以下のいずれかに該当する場合は2往復目を実施する:
2往復目を判断する前に、1往復目の出力にコマンド失敗の兆候がないか確認する。失敗を検知した場合は、まず相談元Agentが正しい情報を取得・補正してから2往復目の要否を判断する（詳細はセクション5「codexのコマンド失敗を検知した場合」を参照）。
2往復目のプロンプト構成:
注意: codex execは単発実行のため、2往復目のCodexは1往復目の記憶を持っていない。最初から文脈を全て含める必要がある。
往復は原則2回まで。3回以上はユーザーに確認してから実施する。
codexの出力を読み取り、以下の構成でユーザーに報告する:
codexに送ったプロンプトの概要を1-2文で説明する。
codexの主な指摘・提案を箇条書きで要約する。
見解の姿勢:
ユーザーと相談すべき事項や、推奨する次のステップを示す。
codexの出力量が多く、要約や処理が困難だと判断した場合は、以下の手順に従う:
事前にプロンプトで出力量を制限しない。制限すると重要な情報が欠落するリスクがある。
codexの出力を読む際、コマンド実行の失敗の兆候がないか注意深く確認する。 兆候の例: エラーメッセージ、「取得できなかった」「失敗した」「permission denied」「not found」など。
失敗を検知した場合は、以下の手順に従う:
gh pr view）をBashツールで実行し、結果を確認するcodexが何らかの失敗をしたパターンを認識したら、次回以降の改善策をユーザーに進言する。