simplify

簡素化

変更されたすべてのファイルを、再利用性、品質、効率性の3つの観点で並列エージェントを通じてレビューし、見つかった問題を修正します。

基本原則

レビュー対象は変更されたコードのみです。各レビュー観点は独立して実行され、差分全体を確認し、他のエージェントの結果を知らない状態で指摘事項を報告します。メインエージェントが結果を集約し、修正を適用します。

必須ゲート

1. レビュー前に変更を特定します。 必ず最初に git diff（ステージ済みの変更がある場合は git diff HEAD）を実行します。変更内容を把握せずにレビューしてはいけません。
2. 3つのエージェントをすべて並列で実行します。 3つのレビューエージェントを順番に実行することは禁止されています。1つのメッセージで3つすべてを同時に実行します。
3. 各エージェントに差分全体を渡します。 エージェントごとに差分を分割したり、絞り込んだりしてはいけません。すべてのエージェントがすべての変更を確認します。
4. 問題を直接修正します。 このスキルでは、報告だけでなくコードを変更します。指摘事項が対応可能であれば修正します。
5. 誤検知は黙ってスキップします。 指摘に対応する価値がなければ、次に進みます。指摘に反論したり、スキップする理由を説明したりしてはいけません。
6. 差分の範囲を超えて作業しません。 変更されたコードのみをレビューします。同じ問題があっても、変更されていないコードをリファクタリングしてはいけません。

使用する場合

• 実装作業の後、コード品質の確認が必要な場合
• ユーザーが「簡素化」「クリーンアップ」「変更をレビュー」「コードをチェック」と依頼した場合
• review-work の前に、run-plan の実行後の中間的な品質確認として
• ユーザーが最近の変更に重複ロジック、非効率な処理、粗雑なパターンがあると考えている場合

使用しない場合

• 変更がない場合（差分が出力されない場合）
• ユーザーがコードベース全体の監査を求めている場合（このスキルのレビュー対象は差分のみです）
• ユーザーがフォーマットまたはリンティングの修正のみを求めている場合
• 目的が計画の検証である場合（代わりに review-work を使用します）

プロセス

フェーズ1：変更の特定

1. git diff を実行して、ステージされていない変更を確認します
2. 出力がなければ、git diff HEAD を実行してステージ済みの変更を確認します
3. それでも出力がなければ、ユーザーが言及したファイル、またはこの会話の前半で編集したファイルのうち、最近変更されたものを確認します
4. 変更を特定できない場合は、ユーザーに通知して終了します

差分全体の出力を取得し、3つすべてのエージェントへの入力として使用します。

フェーズ2：3つのレビューエージェントを並列で起動

Agent ツールを使い、1つのメッセージで3つのエージェントを同時に実行します。各エージェントには差分全体と、以下に記載された該当するレビュー用プロンプトを渡します。

各エージェントに渡すもの：

• フェーズ1で取得した差分全体の出力
• 該当する以下のセクションからそのままコピーした、エージェント用のレビュー・プロンプト

渡してはいけないもの：

• 他のエージェントの指摘事項（各エージェントは独立して実行されます）
• 問題を修正するよう指示する内容（エージェントは指摘事項のみを報告します）

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

次のプロンプトをエージェントに入力してください：

コード差分をレビューし、コード再利用の機会を探してください。コードベースにすでに存在する機能と重複する新しいコードを見つけることが目的です。

差分に含まれる変更ごとに、次のことを行ってください。

1. 既存のユーティリティとヘルパーを検索する：新たに書かれたコードの代わりに使えるものを探します。ユーティリティディレクトリ（utils/、helpers/、lib/、common/、shared/）、変更されたファイルに隣接するファイル、および変更されたファイルからインポートされているファイルを検索してください。
2. 既存の機能と重複する新しい関数を指摘する：新しい関数、既存の関数、および既存の関数が定義されている場所を報告してください。
3. 既存のユーティリティを使えるインラインロジックを指摘する：よくある例として、手作業での文字列操作、手動でのパス処理、独自の環境チェック、その場しのぎの型ガード、手動での配列／オブジェクト変換、インラインでの日時フォーマットがあります。
4. 標準ライブラリ機能の再実装を指摘する：変更によって、言語の標準ライブラリや、すでにインストール済みの依存関係にある機能が再実装されていないか確認してください。

指摘ごとに、次の情報を報告してください。

• 再利用の機会：［簡潔な説明］
• 新しいコード：[ファイル:行番号] — ［書かれた内容］
• 既存のコード：[ファイル:行番号] — ［すでに存在する内容］
• 提案：［置き換え方法］

再利用に関する問題が見つからない場合は、次のように報告してください："No reuse issues found."

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

次のプロンプトをエージェントに入力してください：

コード差分をレビューし、品質上の問題を探してください。ハック的なパターン、不要な複雑さ、抽象化の境界への違反を見つけることが目的です。

次のパターンを確認してください。

1. 冗長な状態：別の変数から常に導出される新しい変数、アクセス時に計算できる値を保持するキャッシュ、直接関数を呼び出せるイベントリスナーやオブザーバー。
2. パラメーターの肥大化：新しいブール値フラグの引数が追加された関数、変更後に引数が4つを超える関数、常に一緒に渡され、単一のオブジェクトにまとめるべき複数の引数。
3. わずかに異なるコードのコピー＆ペースト：1～2行だけ異なる2つ以上のコードブロック、フィールド名だけ異なる条件分岐の繰り返し、複数箇所にある似たエラー処理ブロック。
4. 漏れのある抽象化：モジュールの外部からのプライベートフィールドや内部状態へのアクセス、モジュール境界を越えて渡される実装の詳細、あるモジュールが別のモジュールの内部構造に依存する変更。
5. 文字列依存のコード：すでに定数として定義されている値との新しい文字列比較、新しい文字列リテラルと既存の列挙型またはユニオン型の値との一致、共通の定数なしで複数箇所に現れるマジック文字列。
6. 不要なコメント：コードの動作、変更内容、タスクについて説明するコメントは削除してください。残すのは、隠れた制約、微妙な不変条件、回避策など、明白でない理由を説明するコメントだけです。削除する例：counter++ の上にある // increment counter。残す例：// Redis returns nil for both "key missing" and "value is empty" — we must distinguish。

指摘ごとに、次の情報を報告してください。

• 品質上の問題：［カテゴリ］
• 場所：[ファイル:行番号]
• 問題：［問題の内容］
• 提案：［修正方法］

品質上の問題が見つからない場合は、次のように報告してください："No quality issues found."

エージェント 3：効率性レビュー

次のプロンプトをエージェントに渡してください。

コード差分をレビューし、効率性の問題を探してください。不要な処理、並行実行の見落とし、リソース管理の問題を見つけるのがあなたの役割です。早まった最適化は避け、明らかに不要な処理や明らかに不適切な管理だけを指摘してください。

次のパターンを確認してください。

1. 不要な処理： ループ内で同じ値を複数回計算している、同じファイルを複数回読み込んでいる、結果をキャッシュまたはバッチ処理できるのに同じ API 呼び出しを繰り返している、ループ内のデータベースクエリを WHERE IN を使った単一クエリにできる。
2. 並行実行の見落とし： 独立した処理に対して複数の await 呼び出しを順番に実行している、並列化できるファイル読み込みを順次実行している、独立した API 呼び出しを一つずつ実行している。
3. ホットパスの肥大化： リクエストハンドラーに同期ファイル I/O が追加されている、メモ化できる新たな計算がレンダー関数に追加されている、モジュールの読み込み時に新しい初期化ロジックが追加されている。
4. 繰り返される無変更の更新： 値が変わったか確認せず、すべてのインターバルのティックで状態セッターが呼び出される、変更検知のガードなしでストアのディスパッチがすべてのイベントで発生する、更新コールバックを受け取るのに「変更なし」の戻り値を尊重しないラッパー関数。変更検知のガードを追加し、何も変わっていないときに下流のコンシューマーへ通知されないようにしてください。
5. 不要な存在確認（TOCTOU）： if (existsSync(path)) { readFileSync(path) } のようなコード。存在確認をせずに直接操作し、エラーを処理してください。
6. メモリの問題： 上限なく増え続けるコレクション、対応する削除処理なしに登録されたイベントリスナー、dispose／destroy ハンドラーでクリーンアップされないサブスクリプション、必要以上に長くクロージャのスコープに保持される大きなオブジェクト。
7. 範囲が広すぎる操作： 1つの値を取り出すためにファイル全体を読み込む、IDで1件を探すためにすべてのレコードを取得する、1つのフィールドしか必要ないのに設定全体を読み込む。

指摘ごとに、次の内容を報告してください。

• 効率性の問題： [カテゴリ]
• 場所：[ファイル:行]
• 問題点：[無駄な処理の内容]
• 提案：[修正方法]

効率性の問題が見つからない場合は、「効率性の問題は見つかりませんでした」と報告してください。

フェーズ 3：問題の修正

1. 3つのエージェントすべてが完了するまで待ちます
2. 3つのエージェントの指摘をまとめます
3. 重複する指摘を取り除きます（複数のエージェントが同じコードを指摘する場合があります）
4. 対応が必要な指摘ごとに、次のようにします。
   • 指摘に対応する最小限の修正を適用します
   • 関連のない改善を同じ変更にまとめないでください
   • 修正範囲を指摘された内容より広げないでください
5. 誤検知は何も伝えずにスキップします
6. テストスイートを実行し、リグレッションが発生していないことを確認します
7. 修正後にテストが失敗した場合は、その修正を元に戻し、手動での対応が必要な指摘として報告します
8. 修正内容を簡潔にまとめます（または、コードに問題がなかったことを確認します）

停止するタイミング

• フェーズ 1 で変更が検出されなかった場合 — ユーザーに知らせて停止します
• 3つのエージェントすべてが指摘なしと報告した場合 — コードに問題がないことを確認します
• 修正によってテストが失敗し、範囲を広げずに解決できない場合 — 停止し、リグレッションを報告して、systematic-debugging を提案します

アンチパターン

アンチパターン	失敗する理由
最初に git diff を実行せずにレビューする	変更されていない可能性のあるコードをレビューすることになり、無関係な指摘に時間を費やします
エージェントを順番に実行する	不必要な遅延が発生し、Hard Gate #2 に違反します
各エージェントに差分の一部だけを渡す	複数のファイルにまたがる問題をエージェントが見落とします
指摘を修正せずに報告する	スキルの目的に反し、ユーザーに手作業を求めることになります
スキップした指摘について議論したり説明したりする	コンテキストと時間を浪費します。スキップして先に進んでください
「ついでに」変更されていないコードをレビューする	スコープクリープを招き、Hard Gate #6 に違反します
その後テストを実行せずに問題を修正する	気付かないうちにリグレッションを引き起こすおそれがあります
修正に「ついでの」改善をまとめる	レビューでの修正と無関係な変更が混在し、差分が分かりにくくなります

最小チェックリスト

• git diff を実行して変更を特定しました
• 3 つすべてのエージェントを並列でディスパッチしました（単一のメッセージ）
• 各エージェントに差分全体を渡しました
• 3 つすべてのエージェントの調査結果を集約しました
• 対応が必要な調査結果に対して修正を適用しました
• 根拠のない誤検知はスキップしました
• 修正後にテストを実行し、リグレッションがないことを確認しました
• 結果をユーザーに報告しました

次のステップ

簡素化が完了した後：

• 実装後の品質確認だった場合 → 独立した計画検証のために review-work への移行を提案します
• 問題が見つかり修正した場合 → 修正が適切に行われたことを確認するため、ユーザーが再度 simplify を実行することを提案します
• レビュー中にバグが見つかった場合 → systematic-debugging を提案します

このスキル自体が次のスキルを呼び出すことはありません。結果を報告し、次のステップはユーザーが決められるようにします。