Menu
Codex CLI にコードレビューを依頼する。PR が存在する場合は PR を、ローカルブランチの場合はメインブランチとの差分をレビューする。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | codex-review |
| description | Codex CLI にコードレビューを依頼する。PR が存在する場合は PR を、ローカルブランチの場合はメインブランチとの差分をレビューする。 |
| allowed-tools | Bash, BashOutput, Read, Write, AskUserQuestion |
Codex CLI にコードレビューを依頼する。Claude Code は codex exec で自己完結したレビュープロンプトを渡すだけで、レビュー本体は Codex CLI 側で実施される。
$ARGUMENTS は PR 番号/URL（省略可）。123、#123、PR URL のいずれか。
レビュー依頼は 同梱の sh ラッパー scripts/run-codex.sh 経由で起動する。プロンプトを Bash 引数に直接渡すとシェルメタ文字でクォートが壊れて起動失敗するケースがあるため、プロンプトを必ずファイルに書き出してそのパスを渡す。ラッパー側で --dangerously-bypass-approvals-and-sandbox と </dev/null を付けて、承認プロンプトや stdin 待ちで止まらないようにする。
Write ツールで tmp/codex-prompt-<タイムスタンプ>.txt などの一時ファイルに以下の本文を書き出す。プレースホルダは書き出し時に展開する:
<ARGS>: $ARGUMENTS をそのまま展開する（空なら空文字列のまま）<BASE>: tmp/config.json の base_branch。無ければ git remote show origin の HEAD branch を検出して tmp/config.json に保存し、その値を使う以下の手順でコードレビューを実施してください。
## 手順
### 1. 差分の取得
- PR 番号/URL が指定された場合: `gh pr view` で PR 情報を取得し、`gh pr diff` で差分を取得（PR モード）
- PR 番号/URL が空の場合: `gh pr view` を試み、現在のブランチに PR が存在するか確認する
- PR が存在する → PR モードで差分を取得
- PR が存在しない → `git diff <BASE>...HEAD` でベースブランチとの差分を取得（ローカルモード）
### 2. 情報収集
- PR モードの場合、PR の情報（タイトル、説明、関連 issue）を把握する
- 関連する issue がある場合は `gh issue view` で issue の目的・要件を把握する
- ローカルモードの場合、`tmp/issues/<issue番号>/` 配下の既存成果物を確認する:
- `plan.md` — 実装計画。意図した設計や変更方針との整合性を確認(md が無ければ `plan.html`。以降も同様)
- `report.md` — 実装レポート。実装者が認識している懸念点や追加変更を把握
- `implementation-notes.md` — 実装ノート。計画からの逸脱(Deviations)と実装中の判断を把握
- `checklist.html` — 受け入れテストチェックリスト。テストの網羅性を検証する基準
- `pr.md` — PR テキスト。PR の説明と実際の差分に乖離がないか確認
### 3. レビュー実施
変更ファイルごとにコードベースの該当箇所を読み、以下の観点でレビューする。出力フォーマットは `skills/codex-review/assets/template.html` を参照（**HTML で出力する**）:
- **正確性**: ロジックにバグや抜け漏れがないか
- **設計**: 責務分離、命名、既存パターンとの一貫性
- **副作用 / 影響範囲**: 変更・削除・リネームしたシンボル（関数・型・定数・ファイルパス・設定キー等）の参照元が壊れていないか。シグネチャ変更による型エラー、削除した機能の呼び出し元、挙動変更による既存フローへの影響を `grep` 等で網羅的に確認する
- **セキュリティ**: インジェクション、認証・認可の不備、機密情報の漏洩がないか
- **パフォーマンス**: N+1 クエリ、不要な再レンダリング、計算量の問題がないか
- **テスト**: テストの網羅性、境界値・異常系のカバレッジ
- **可読性**: 複雑すぎるロジック、不明瞭な命名、過剰な抽象化がないか
### 4. 結果の保存
- PR モード: `tmp/prs/<PR 番号>/review-codex.html`
- ローカルモード: `tmp/issues/<issue 番号>/review-codex.html`
- `mkdir -p` で出力先ディレクトリを作成してから書き込む
- 出力は `skills/codex-review/assets/template.html` のスタイルに準拠した完結した HTML ドキュメント（`<!DOCTYPE html>` から `</html>` まで）とする。重要度バッジ（must/should/nit）と観点タグの CSS クラスはテンプレートのものをそのまま利用する
## 注意事項
- 軽微なスタイルの指摘（空白、改行など）はリンターに任せ、レビューでは扱わない
- 指摘には必ず該当ファイルと行番号を含める
- 指摘ごとに重要度（must / should / nit）を付与する
- 良い点も積極的にコメントする
## 引数
<ARGS>
codex exec を起動Bash ツールで以下を実行する（<prompt-file> は 1-1 で書き出したファイルの絶対パス、<skill-dir> はこの skill のディレクトリの絶対パス）:
<skill-dir>/scripts/run-codex.sh <prompt-file>
codex exec --dangerously-bypass-approvals-and-sandbox <prompt> </dev/null を実行するrm 不要）Codex CLI の実行完了後、ls で以下のいずれかが存在することを確認する:
tmp/prs/<PR 番号>/review-codex.htmltmp/issues/<issue 番号>/review-codex.htmlファイルが生成されていない場合は codex exec を再実行する（最大 2 回まで）。
生成された review-codex.html の内容を要約してユーザーに提示する。
Integrate Firebase Auth (authentication + domain restriction) into internal applications. Includes domain restriction via Blocking Functions and user registration to Firestore.
chrome-devtools-mcp の CLI (`chrome-devtools`) を使ったブラウザ操作の総合スキル。既存ブラウザへの attach / 使い捨てテストブラウザ / ログイン状態を保持する永続プロファイルのいずれかをユーザーに必ず確認した上でサーバを立ち上げ、スナップショット取得・クリック・入力・ナビゲーション・スクショ・ネットワーク監視などを行う。
Access the Firebase Emulator Suite (Firestore, Auth, Functions, Hub) via REST and Admin SDK without trial-and-error. Use this skill whenever you read/write/query/clear Firestore Emulator data, create test users or obtain ID tokens from the Auth Emulator, verify Functions triggers, seed/export emulator data, or hit unexpected 403/404 from an emulator endpoint. Consult it BEFORE curling any emulator port — it encodes the auth header and host-resolution rules that otherwise cause retries.
GitHub issue と実装計画をもとにコードを実装する。計画からの逸脱は implementation-notes.md に記録しながら進める。
GitHub PR のレビューコメントを評価するスキル。コメントの妥当性をコードベースで独立検証し、対応可否の判定・返信文案の作成・(指示があれば)修正実装まで行う。ユーザーが PR コメントの URL を貼って「評価して」「考察して」「妥当性を判断して」「対応可否を考えて」「どう思う？」などの意図を示したら必ず使用する。
GitHub issue から計画・実装・テスト・レビュー・PR テキスト・理解確認まで一気通貫で行う。