Agent skill
codex-review
コードレビューを依頼された際に使用。Codex CLIを使ってplanファイルと開発日誌(コンテキストにある場合)を参照し、実装が計画に沿っているかをレビューし、指摘をタスクリスト化して収束するまで繰り返します。
Install this agent skill to your Project
npx add-skill https://github.com/syou6162/claude-code-commands/tree/main/skills/codex-review
SKILL.md
Codex CLIを使ったコードレビュー
コードの変更内容に対してcodex CLIを使って客観的なレビューを実施します。
実行手順
1. デフォルトブランチの取得
まず、リポジトリのデフォルトブランチを取得してください:
git symbolic-ref refs/remotes/origin/HEAD --short | cut -d/ -f2
このコマンドでデフォルトブランチ名(main や master など)を取得し、後続のステップで使用します。
2. planファイルの特定
.claude_work/plans/配下からplanファイルを取得してください:
ls .claude_work/plans/*.md
git worktree運用のため、単一のplanファイルが存在する前提です。
このファイルパスを以下のように定義します:
<取得したplanファイルのパス>
3. 開発日誌の取得(コンテキストにある場合)
会話のコンテキスト内にesa URLの開発日誌が言及されている場合、以下の手順で取得してください:
3.1 post番号の抽出
esa URLからpost番号を抽出(例:https://yasuhisa.esa.io/posts/1234 → 1234)
3.2 YAMLの直接取得
esa-llm-scoped-guard fetch コマンドでYAMLを直接取得:
esa-llm-scoped-guard fetch -post <post_number> | tee .claude_work/dev_diary.yaml
成功の場合: YAMLが .claude_work/dev_diary.yaml に保存されるので、次のステップへ進む
失敗の場合: エラーメッセージをユーザーに報告し、このステップをスキップ
開発日誌がコンテキストにない場合は、このステップ全体をスキップしてください。
4. planファイルとの整合性確認
Codexレビュー前に、planファイルを読んで現在の実装(diff)との整合性を確認してください:
- タグで定義されたパスのファイルを読む(Readツール使用)
- デフォルトブランチとの差分を確認(
git diff <デフォルトブランチ名>...HEAD) - planの内容と実装にずれがないか確認
- ずれがある場合はユーザーに報告
5. Codex CLIでのレビュー実行
Bash経由でcopilot --model gpt-5.3-codexを使ってレビューを実行してください。
重要: コマンドはリポジトリルートで実行すること(相対パスが前提)
開発日誌がない場合のコマンド例:
echo "<デフォルトブランチ名>ブランチとの差分を日本語でレビューしてください。
以下のファイルを参照して、計画に沿った実装になっているか確認してください:
- planファイル: <plan-fileタグで定義されたパス>
- ユーザー発言ログ: .claude_work/user_prompts.txt(存在する場合)
## レビュー方針
- **時間をかけてコードベースを徹底的に読むこと**
- 差分で変更されたファイルや関連ファイルはすべて確認すること
- 網羅的にレビューし、指摘漏れがないようにすること
- 各観点について具体的なコード箇所を参照しながらレビューすること
- **レビュー結果が網羅的で一度に多くなっても構わない**(指摘は詳細かつ具体的に)
レビューの観点:
- planに記載された変更内容との整合性
- コードの品質(可読性、保守性)
- 潜在的な問題やバグ
- ユーザー意図との整合性: .claude_work/user_prompts.txt に記録されたユーザーの発言・指示と実装が整合しているか" | copilot --model gpt-5.3-codex
開発日誌がある場合のコマンド例:
echo "<デフォルトブランチ名>ブランチとの差分を日本語でレビューしてください。
以下のファイルを参照して、計画に沿った実装になっているか確認してください:
- planファイル: <plan-fileタグで定義されたパス>
- 開発日誌: .claude_work/dev_diary.yaml
- ユーザー発言ログ: .claude_work/user_prompts.txt(存在する場合)
## レビュー方針
- **時間をかけてコードベースを徹底的に読むこと**
- 差分で変更されたファイルや関連ファイルはすべて確認すること
- 網羅的にレビューし、指摘漏れがないようにすること
- 各観点について具体的なコード箇所を参照しながらレビューすること
- **レビュー結果が網羅的で一度に多くなっても構わない**(指摘は詳細かつ具体的に)
レビューの観点:
- planに記載された変更内容との整合性
- コードの品質(可読性、保守性)
- 潜在的な問題やバグ
- 開発日誌に記載された開発指針との整合性
- ユーザー意図との整合性: .claude_work/user_prompts.txt に記録されたユーザーの発言・指示と実装が整合しているか" | copilot --model gpt-5.3-codex
copilot CLIが失敗した場合のフォールバック:
copilot --model gpt-5.3-codex の終了コードが0以外(weekly limitやその他のエラー)の場合、同じプロンプトをCodex CLIで実行してください:
echo "<同じレビュープロンプト>" | codex review -
- ファイルの内容ではなく、ファイルパスを渡すことで、Codexが直接ファイルを読み取ります
- 毎回新規セッションでレビューすること(
resumeは使用禁止) - Codexは過去のレビュー結果や前回の指摘には一切言及しないこと
- Codexはプロンプトに記載された観点のみでレビューすること(「前回の指摘は直りましたか?」などの余計な質問をしない)
6. レビュー結果の処理
6.1 レビュー結果の確認
Codexの出力(Bashツールの実行結果)から、指摘内容を把握する。
6.2 指摘の分類とタスクリスト化
指摘を以下のように分類し、必ずClaude CodeのTaskCreate/TaskUpdateツールを使ってタスクリストに追加する:
| 分類 | 対応 |
|---|---|
| 実装上の指摘・改善提案 | TaskCreateでタスクリストに追加 |
| 仕様に関する質問 | TaskCreateでタスクリストの最後に追加(ユーザーに確認) |
- すべての指摘はClaude CodeのTaskCreateツールでタスクリストに入れること(忘れ防止)
- 同じ指摘が既にタスクリストにある場合は、新規作成せずTaskUpdateで更新する(重複防止)
- 仕様に関する質問は、他のタスクを処理した後でユーザーに確認する
- タスクの更新にはTaskUpdateツールを使用
6.3 タスクの実行
- タスクリストの順番に従って対応
- 仕様に関する質問はタスクの最後でユーザーに確認
6.4 収束確認とループ
再レビューが必要な場合(前回のCodexレビューで指摘が1件以上あった場合、ただし強制停止条件に該当する場合を除く):
- 最大レビュー回数(10回)に達していない場合のみ「Codexレビューを再実行する」タスクをリストに追加
- 手順5に戻ってCodexレビューを再実行
収束条件(以下を満たした場合のみ収束と判定する):
- Codexレビューを実行した結果、指摘が0件だった(初回レビュー・再レビューを問わない)
強制停止条件(収束ではなく停止として扱う):
- 最大レビュー回数(10回)に達した
- 同一の指摘が繰り返された
- 修正しただけでは収束ではない: 指摘に対して修正を行った場合、必ずCodexレビューを再実行し、指摘が0件であることを確認すること。修正完了をもって収束と判定してはならない
- 指摘が0件になるまで基本的にループを続けること(最大10回まで)
- レビュー回数の管理: タスク名に回数を含める(例:「Codexレビューを再実行する(2回目)」)
- 最大レビュー回数に達した場合は、それ以上レビュー再実行タスクを追加せず停止する
- 同一の指摘が繰り返される場合は停止し、「以下の指摘が繰り返されたため停止しました」とユーザーに報告(繰り返された指摘内容を明記)
- 収束確認のためのレビュー再実行もタスクリストに入れること
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
assembling-dev-team
「開発チーム集合」「チームで実装」「チーム編成して」の言及時に使用。プランファイルに基づいて実装・リリース・レビュー・プラン更新の4担当をスポーンし、ステップごとに実装→レビュー→リリースのサイクルを回す。
requesting-gcloud-bq-auth
gcloudやbqコマンド実行時に認証エラー(Reauthentication required等)を検出した場合に使用。エージェントが自動で認証コマンドを実行することを防ぎ、ユーザーに認証を依頼します。
planning-guardrails
Plan modeや計画作成・プラン作成の依頼時に必ず発動し、必須セクションを漏れなく含む計画を作るためのガードレールを提供します。参考情報(URL/過去PR/ファイルパス)とユーザー発言(要約+生ログ)を必須化し、テストがある場合はTDD前提と正常系/異常系テストケース記載を強制します。
updating-pr-title-and-description
Pull Request作成・更新時に使用。タイトルと説明文を自動生成・更新する。
ask-user-choice
ユーザーに質問や確認をする際に毎回発動してください。自由回答形式ではなく、明確な選択肢(1質問あたり2-4個)を持つAskUserQuestionツールを使用し、ユーザーの入力負担を軽減して意思決定を迅速化します。柔軟性のためmultiSelect trueをデフォルトにしてください。
semantic-committing
コミット時、「commit」「git add」「変更を分割」の言及時に使用。git diffを分析し、変更を論理的な意味単位に分割してコミットする。git-sequential-stageでhunk単位のステージングを行う。
Didn't find tool you were looking for?