simplify-code

コードを簡潔にする

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

モード

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

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

ユーザーがモードを指定していない場合は、次をデフォルトにします。

• 「review」、「audit」、「check」の場合はreview-only
• 「simplify」、「clean up」、「refactor」の場合は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. 既存の型付きコントラクト、列挙型、定数があるのに文字列で表現されている値

サブエージェント 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: 結果を要約

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

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

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