review-and-simplify-changes

変更のレビューと簡素化

変更されたコードをレビューし、再利用性、品質、効率性、明確さに関する問題を確認します。Codex のサブエージェントを使って並行してレビューしますが、サブエージェントは読み取り専用にしてください。コードを調査して、見つかった問題をメインエージェントに報告するだけにします。確信度の高い、動作を変えない修正を適用できるのはメインエージェントだけです。

モード

ユーザーの依頼に応じてモードを選択します。

• review-only：ユーザーが変更のレビュー、監査、確認を依頼した場合
• safe-fixes：ユーザーが変更の簡素化、整理、リファクタリングを依頼した場合
• fix-and-validate：safe-fixesと同じですが、編集後に最小限の関連検証も実行します

ユーザーがモードを指定していない場合は、次を既定とします。

• 「レビュー」「監査」「確認」の場合はreview-only
• 「簡素化」「整理」「リファクタリング」の場合はsafe-fixes

ステップ 1：範囲と差分コマンドを決める

範囲は、次の順に優先します。

1. ユーザーが明示したファイルまたはパス
2. 現在の Git の変更
3. 現在の Codex ターンで先に編集されたファイル
4. レビューの依頼があるものの差分がない場合に限り、直近に変更された追跡対象ファイル

範囲が明確でない場合は、簡潔にその旨を伝えて終了します。

Git の変更を対象にする場合は、リポジトリの状態に応じて最小かつ適切な差分コマンドを選びます。

• ステージされていない変更：git diff
• ステージされた変更：git diff --cached
• ブランチまたはコミットとの比較が明示的に依頼された場合：指定された差分対象を使用します
• ステージ済みと未ステージの変更が混在する場合：両方をレビューします

既定でgit diff HEADが適切だと決めつけてはいけません。より小さい差分が利用できる場合は、そちらを使います。

規約を確認したり修正を適用したりする前に、リポジトリ内の指示ファイルと、変更対象に関連するプロジェクトのドキュメントを読みます。次のような、該当範囲に最も近いガイダンスを優先します。

• AGENTS.md
• リポジトリのワークフロー文書
• 変更対象モジュールのアーキテクチャ文書やスタイルガイド

これらの指示を参照し、実際の問題と、意図されたローカルの慣例を区別します。

ステップ 2：読み取り専用のレビューサブエージェントを 4 つ並行して起動する

範囲が並行レビューに適している場合は、Codex のサブエージェントを使用します。非常に小さな差分やファイル 1 つだけの場合は、ローカルでレビューしてもかまいません。

サブエージェントを起動する場合は、次のようにします。

• 各サブエージェントに同じ範囲を指定します
• 各サブエージェントに、担当するレビュー観点だけを調査するよう指示します
• 読み取り専用のレビューであることを伝えます
• ファイルの編集、apply_patchの実行、変更のステージ、コミット、その他の状態を変更する操作を禁止します
• 簡潔で構造化された指摘のみを返すよう依頼します
• ファイル、行またはシンボル、問題、推奨する修正、確信度を報告するよう依頼します
• 指摘はメインエージェントにのみ返し、サブエージェント自身は修正を実装しないよう指示します

レビューの役割は 4 つです。

サブエージェント 1：コード再利用のレビュー

変更を確認し、再利用できる箇所を探します。

1. 同じ問題をすでに解決している既存のヘルパー、ユーティリティ、共有抽象化を検索します。
2. 変更によって導入された、重複する関数やほぼ同一のロジックを指摘します。
3. 既存のヘルパーを使わずにインラインで再実装している箇所を指摘します。

このサブエージェントは読み取り専用です。ファイルの編集、パッチの適用、その他のワークスペースの変更を行ってはいけません。

推奨するサブエージェントの役割：広範なコードベース調査にはexplorer、広範な検索よりも詳細なレビューが有用な場合はreviewer。

サブエージェント 2：コード品質のレビュー

同じ変更について、次のようなコード品質上の問題を確認します。

1. 不要な状態、キャッシュ値、派生値の保存
2. 既存の呼び出し経路に新しい引数を渡して増える、パラメーターの過剰な増加
3. わずかな違いを伴うコピー＆ペーストが、共有抽象化にまとめられるべき箇所
4. 抽象化の漏れや、モジュール境界を越えた責務違反
5. 既存の型付きコントラクト、列挙型、定数があるのに、文字列で型を表現している箇所

このサブエージェントは読み取り専用です。ファイルの編集、パッチの適用、その他のワークスペースの変更を行ってはいけません。

推奨するサブエージェントの役割：reviewer

サブエージェント 3: 効率性レビュー

同じ変更について、効率性の問題をレビューします:

1. 繰り返しの作業、重複した読み取り、重複した API 呼び出し、または不要な再計算
2. 安全に並行実行できるはずの逐次処理
3. 明確な必要性がないまま、起動、レンダリング、リクエスト、その他のホットパスに追加された新しい処理
4. 操作自体を直接試してエラーを処理できるのに、存在確認を事前に行っている
5. メモリの増加、クリーンアップの欠如、リスナーやサブスクリプションのリーク
6. コードが必要とするのは一部だけなのに、過度に広範な読み取りやスキャンを行っている

このサブエージェントは読み取り専用です。ファイルの編集、パッチの適用、その他のワークスペースへの変更を行ってはいけません。

推奨するサブエージェントの役割: reviewer

サブエージェント 4: 明確さと標準のレビュー

同じ変更について、明確さ、ローカル標準、バランスをレビューします:

1. ローカルプロジェクトの慣習やモジュールパターンへの違反
2. 不要な複雑さ、深いネスト、弱い命名、冗長なコメント
3. 可読性を低下させる、過度に詰め込まれた、または技巧的なコード
4. 別々の関心事を 1 つの不明瞭な単位にまとめてしまう過度な単純化
5. デッドコード、デッドな抽象化、価値のない間接化

このサブエージェントは読み取り専用です。ファイルの編集、パッチの適用、その他のワークスペースへの変更を行ってはいけません。

推奨するサブエージェントの役割: reviewer

保守性、正確性、コストを実質的に改善する問題だけを報告してください。見た目を変えるためだけにコードをいたずらに変更しないでください。

ステップ 3: 指摘の集約

すべてのレビューサブエージェントが完了するのを待ってから、それらの指摘を統合します。

このステップはメインエージェントが担当します。サブエージェントの出力はレビュー入力としてのみ扱い、コード変更を委譲する許可とはみなしません。

指摘を次の形に正規化します:

1. ファイルと行、または最も近いシンボル
2. カテゴリ: 再利用、品質、効率性、明確さ
3. なぜ問題なのか
4. 推奨する修正
5. 信頼度: 高、中、低

編集の前に、弱い指摘、重複した指摘、指示と矛盾する指摘は破棄してください。

ステップ 4: 問題を慎重に修正

review-only モードでは、指摘を報告したら停止します。

safe-fixes または fix-and-validate モードでは:

• このスキルの修正を適用するのはメインエージェントだけです
• 信頼度が高く、動作を保持する修正のみを適用します
• 製品やアーキテクチャの判断を必要とする主観的なリファクタリングはスキップします
• ローカルパターンが意図的なものである場合、または指示に基づくものである場合は保持します
• 修正を正しく完了するために隣接する小さな変更が必要な場合を除き、編集はレビュー対象のファイルに限定します

次のような修正を優先します:

• 重複したコードを既存のヘルパーに置き換える
• 冗長な状態やデッドコードを削除する
• 動作を変えずに制御フローを単純化する
• 過度に広範な操作を絞り込む
• スコープが限定的な場合に、不明瞭なローカル変数の名前を変更する

このスキルの一環として、変更をステージ、コミット、プッシュしないでください。

ステップ 5: 必要に応じて検証

fix-and-validate モードでは、メインエージェントが編集を終えた後に、対象スコープに対して最小限の関連する検証を実行します。

例:

• 対象モジュールに対する的を絞ったテスト
• 対象ターゲットに対する型チェックまたはコンパイル
• それがプロジェクトの実質的な安全ゲートである場合のフォーマッターまたはリントチェック

変更の広がりがより多くの検証を正当化しない限り、フルスイートの実行よりも高速でスコープを絞った検証を優先します。

ユーザーが実行しないよう求めたために検証をスキップする場合は、その旨を明示してください。

ステップ 6: 結果を要約

最後に簡潔な結果を示します:

• 何をレビューしたか
• 何を修正したか (修正した場合)
• 意図的にそのままにしたものは何か
• 検証を実行したかどうか

このルーブリックに対してコードがすでにクリーンである場合は、編集をでっち上げるのではなく、そのまま伝えてください。