simplify-code

コードの簡素化 — 並行レビューとクリーンアップ

直近のコード変更を、4 人の重点レビュアーで並行してレビューし、結果を集約して、適用する価値のある修正を適用します。

これはクリーンアップであり、バグ探しではありません。 すでに動作しているコードの品質を高めるため、重複を取り除き、不必要な複雑さを減らし、無駄を省き、応急処置的な修正を根本から改善します。ここで正しさに関するバグを探し回らないでください。それは requesting-code-review の役割です。

基本原則： 1 人の幅広いレビュアーより、4 人の対象を絞ったレビュアーのほうが効果的です。それぞれが、再利用性、品質、効率性、抽象度のいずれか 1 つの問題に集中してコードベースを深く調べます。4 つすべてに注意を分散させることはありません。並行して実行するため、かかる時間は 4 回分ではなく 1 回分です。

使用するタイミング

ユーザーが次のいずれかを言ったときに、このスキルを実行します。

• 「簡素化して」／「変更を簡素化して」／「この変更を簡素化して」
• 「コードをレビューして」／「直近の変更をレビューして」／「変更をクリーンアップして」
• 「/simplify」（Claude Code での習慣を引き継いでいる場合）

ユーザーが追加する可能性のある修飾条件 — 必ず反映してください。

• 重点：「効率性に重点を置いて簡素化して」→ 効率性レビュアーのみを実行します（または、集約時に効率性を重視します）。認識される重点項目は reuse、quality（simplification も受け付けます）、efficiency、altitude です。
• ドライラン：「簡素化して、ただし変更はしないで」／「報告だけして」→ 4 人のレビュアーを実行して、結果を提示します。修正は一切適用しません。適用する前に確認してください。
• 対象範囲：「直近のコミットを簡素化して」／「ステージ済みの変更を簡素化して」／「src/foo.py を簡素化して」→ 差分の取得元をそれに合わせて絞ります（フェーズ 1 を参照）。

編集のたびに自動実行したり、無関係なタスクの最後に追加したりしないでください。4 つのサブエージェント分のトークンを消費するため、ユーザーが明示的に依頼した場合にのみ実行します。

プロセス

フェーズ 1 — 変更内容を特定する

レビュー対象の差分を取得します。ユーザーの依頼に応じて、次の優先順で取得元を選びます。

# 1. Default: uncommitted working-tree changes (tracked files)
git diff

# 2. If that's empty, include staged changes
git diff HEAD

# 3. Scoped variants the user may request:
git diff --staged                 # "staged changes"
git diff HEAD~1                    # "the last commit"
git diff main...HEAD              # "this branch" / "my PR"
git diff -- src/foo.py            # specific file(s)

git diff と git diff HEAD がどちらも空で、Git リポジトリがないか変更が存在しない場合は、ユーザーが明示的に指定したファイル、またはこのセッションで最近作成・編集されたファイルに切り替えます。変更されたコードが本当に見つからない場合は、その旨を伝えて終了します — 簡素化するものはありません。

差分全体を取得します。そのサイズも確認します。非常に大きい場合（たとえば変更行数が 2000 行を超える場合）は、4 つのサブエージェントそれぞれに差分全体を渡すと多くのトークンを消費することをユーザーに伝え、続行する前に対象を（ディレクトリ単位、コミット単位で）絞るか提案します。

フェーズ 2 — 4 人のレビュアーを並行して起動する

delegate_task のバッチモードを使います — 4 つのタスクを 1 つの tasks 配列にまとめて渡し、並行して実行します。このパターンでは 4 つに分けるのが適切です。標準的なインストールであれば、delegation.max_concurrent_children の上限内に収まります。

委譲できない場合は？ このコンテキストで delegate_task を呼び出せない場合（リーフサブエージェントである、委譲が無効である、または予算を使い切っている場合）は、レビューを省略したり、観点を減らしたりしないでください。このコンテキスト内で、4 つのレビュアーの観点すべてを順番に検討します — 同じ検索基準、同じ指摘形式を使ってください。最終的な要約では、並行して実行したのではなく、単一パスのインラインレビューだったことを明確に伝え、実際に行った内容がユーザーに分かるようにします。

すべてのレビュアーに、完全な差分（断片ではなく — ファイルをまたぐ問題は断片の間に隠れていることがあります）と、広範なコードベースを検索できるようリポジトリの絶対パスを渡します。各レビュアーには terminal、file、search のツールセットを割り当てます（これにより git、read_file、search_files／grep を実行できます）。 各レビュアーに次の指示を出してください。

• 差分だけから判断せず、既存のコードベースを検索して根拠を確認します。
• **チェスタトンの柵の原則を適用します。**削除を指摘する前に、該当行に対して git blame を実行し、その行が存在する理由を確認します。元の目的が特定できない場合は、 推測せずに confidence: low とします。
• 具体的なコスト、確信度、リスクを含む構造化された出力で指摘を報告します。

  file:line → problem → cost (what's duplicated/wasted/harder to maintain) → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
  

  cost フィールドによって、各指摘はその妥当性を説明する必要があります。実際の問題によるコストを 明確に示せない指摘は、単なる細かい指摘である可能性が高いです。
  • SAFE = 挙動に影響しないことが証明されているもの（未使用のインポート、コメントアウトされた コード、処理をそのまま通すラッパー）。これらは自動適用します。
  • CAREFUL = セマンティクスを変えずに改善できるもの（ローカル変数名の変更、 ネストした三項演算子の平坦化、ヘルパーの抽出）。テストで検証してから適用します。
  • RISKY = 挙動が変わる可能性がある、または公開コントラクトを破るもの（N+1 の再構成、公開 API の名前変更、メモリライフサイクルの変更）。人間によるレビューが必要なものとして指摘し、 自動適用はしません。
• 細かい指摘やスタイルだけの変更は避けます。コードを実質的に改善するものだけを指摘します。

次の4つの目標に合格してください（ユーザーの優先事項から除外されている目標は省略します）。

レビュアー 1 — コードの再利用

この差分に、コードベース内ですでに実装されている機能と重複するコードがないかレビューします。 ユーティリティモジュール、共有ヘルパー、隣接するファイルを検索（search_files / grep を使用）し、 新しいコードが再実装する代わりに呼び出せる既存の関数、定数、パターンを探します。次の点を指摘します。 既存の関数と重複する新しい関数、既存のユーティリティで実行できる手書きのロジック （手動の文字列／パス操作、独自の env チェック、その場しのぎの型ガード、パーサーの再実装）。 それぞれについて、使用すべき既存の要素とその場所を示します。

レビュアー 2 — コード品質

この差分に品質上の問題がないかレビューします。次の点を確認します。冗長な状態 （既存の状態と重複する、または既存の状態から導出できる値、不要なキャッシュ）、 パラメーターの肥大化（関数を再構成すべきところに新しいパラメーターを追加している）、 バリエーション付きのコピー＆ペースト（共通の抽象化を使うべき類似ブロック）、 抽象化の漏れ（内部情報の露出、既存のカプセル化境界の破壊）、 文字列による型指定（定数／enum／レジストリがすでに存在するのに生の文字列を使っている。指摘する前に 正式なレジストリを確認すること）、深くネストした条件分岐（三項演算子の連鎖、3段以上の if/else ピラミッド。ガード節、早期リターン、ルックアップテーブルで平坦化すること）、 AI 生成コードによくある粗雑なパターン（count++ の前にある // increment counter のように 明白なコードを言い換えるだけの余計なコメント、すでに検証済みの入力への不要な防御的 null チェック、 型システムを迂回する as any キャスト、ファイルの他の部分と一貫しないパターン）。 それぞれについて、具体的なリファクタリングを提示します。

レビュアー 3 — 効率性

この差分に効率性の問題がないかレビューします。次の点を確認します。不要な処理 （冗長な計算、ファイルの繰り返し読み込み、API の重複呼び出し、N+1 アクセスパターン）、 並行処理の見落とし（独立した処理を逐次実行している）、ホットパスの肥大化 （起動時やリクエストごとの処理での重い／ブロッキングな作業）、 TOCTOU のアンチパターン（操作を実行してエラーを処理する代わりに、操作前に存在確認をする）、 メモリの問題（無制限な増加、クリーンアップ不足、リスナー／ハンドルのリーク、囲んでいるスコープ全体を クロージャとしてキャプチャする長寿命のコールバックやオブジェクト。キャプチャされたものはすべて オブジェクトと同じ期間メモリに残るため、必要なものだけをコピーする小さなクラスや 明示的なフィールドを持つ構造体を優先すること）、過度に広範な読み込み（必要な範囲だけでよいのに ファイル全体を読み込んでいる）、失敗の握りつぶし（空の catch ブロック、無視されたエラーの戻り値、 except: pass、処理を伴わない .catch(() => {})、エラー伝播の欠落。これらはバグを隠すため、 少なくとも握りつぶす前にログを出す必要があります）。それぞれについて、具体的な修正方法と、 それによって高速化または安全性向上につながる理由を提示します。 レビュアー 4 — 修正の深さ この差分に、修正の深さが適切でない変更がないか確認します。共有インフラ自体を修正せず、その上に応急処置を重ねている変更です。浅すぎる修正の兆候としては、特定の呼び出し元に対応するために汎用コードパスへ特例を追加すること（if (caller == X) 分岐、型チェック、マジック値による回避策など）、兄弟関係にある呼び出し箇所には同じ欠陥が残ったまま、呼び出し箇所で症状だけを修正すること、以前の回避策の上にさらに回避策を重ねること、実際に変更が必要な対象に手を加えずに済むようラッパーを追加すること、壊れたデフォルトを修正せず、設定やフラグを導入して回避することなどがあります。それぞれについて、変更が回避している根本的な仕組みを特定し、より根本的な修正（共有パスの汎用化、根本的なデフォルトの修正、またはバグの種類全体の修正）を説明してください。また、より根本的な修正の規模が大きく、このクリーンアップではなく別タスクにすべき場合は、その旨を率直に記してください。まず周辺コードと git blame を確認してください。応急処置に見えるものが、互換性シム、段階的な移行、ベンダーコードの分離など、意図的な境界である場合もあります。そうしたものは指摘しないでください。

フェーズ 3 — 集約して適用する

4 人全員のレビューが返るまで待ちます（バッチモードではまとめて返されます）。

1. 指摘を統合し、レビュアー間で重複するものを整理します。2 件の指摘が同じ行または同じ根本的な仕組みを対象としている場合は、1 件にまとめます。
2. 誤検知を除外します。最も多くの文脈を把握しているのはあなたです。レビュアーに反論する必要はなく、弱い提案や誤った提案は黙って除外してください。
3. 意見の相違を解決します。レビュアー同士で意見が異なることがあります（レビュアー 1：「既存のユーティリティ X を使う」、レビュアー 3：「X は遅いのでインライン化する」など）。解決の優先順位は、正確性 > ユーザーが明示した重点 > 可読性／再利用性 > マイクロ最適化です。対象のパスが実際に頻繁に実行されるのでなければ、明瞭さを損なうパフォーマンス上の「修正」は適用しないでください。相互に両立せず、どちらにも妥当性がある提案については、変更範囲が小さい方を選び、もう一方の案にも言及してください。
4. リスクの段階に沿って適用します。
   • SAFE を最初に適用します（自動適用）。未使用のインポート、コメントアウトされたコード、単なる受け渡しをするラッパー、冗長な型アサーションが対象です。適用後にテストを実行します。
   • CAREFUL を次に適用します（確認しながら、ファイルごとに適用）。ローカル変数の名前変更、三項演算子の単純化、ヘルパーの抽出、重複コードの統合が対象です。各ファイルの適用後にテストを実行します。問題が起きた場合は元に戻します。
   • RISKY は最後に適用します（レビュー用に提示し、自動適用しない）。N+1 の再構成、公開 API の変更、並行処理の修正、エラー処理の変更が対象です。それぞれについて、リスクの説明とテストカバレッジの状況を提示します。修正の深さを見直す指摘は通常この段階に該当します。より根本的な修正では共有インフラに手を加えることになるため、今すぐ実施するか、後続タスクにするかはユーザーが判断できるよう、修正案を提示します。 ユーザーがドライランを選択した場合は、3 段階すべてを提示し、何も適用しないでください。
5. 変更を検証し、問題がないことを確認します。変更したファイルを対象とするプロジェクトのテスト（全テストスイートではなく、対象を絞ったテスト）を実行し、リポジトリで使用されているリンターや型チェックも再実行します。修正によってテストが失敗した場合は、その修正を元に戻して報告します。
6. 変更内容を要約します。レビュアーのカテゴリとリスク段階ごとに、適用した修正を簡潔に列挙し、意図的に見送った指摘とその理由も示します。委任せずインラインで実行した場合は、その旨もここに記載します。

注意点

• 並列化は4つを超えないでください。 レビュアーを増やしても、コストと調整が必要な競合する提案が増えるだけで、網羅性は向上しません。4つのカテゴリで全領域をカバーできます。
• 各レビュアーに差分全体を渡してください。 差分をレビュアー間で分割すると、この設計の意味がなくなります。ファイルをまたぐ重複やN+1問題は、全体像を見なければ見つかりません。
• レビュアーには検索させ、推測させないでください。 既存のユーティリティへの参照（「おそらくこれ用のヘルパーがあります」）を示さない再利用に関する指摘はノイズです。file:line の根拠を必須にし、それがない指摘は除外してください。
• 適用することと書き直すことは別です。 これはユーザーが最近行った変更を整理するものであり、モジュール全体をリファクタリングする許可ではありません。編集は差分が触れた範囲と、修正に必要な最小限の周辺変更に限定してください。高度に関する指摘は例外ですが、それが原則を裏付けています。適切な修正が差分より深い箇所に及ぶ場合は、指摘してください。整理の過程で共有メカニズムを独断で作り直してはいけません。
• バグ探しに脱線しないでください。 レビュアーが実際の正確性のバグを見つけた場合は、目立つ形で報告してください。ただし、整理の修正に含めず、「バグを発見」という別の注記にしてください。正確性のレビューは、検証基準も異なる別の工程です。
• プロジェクトの規約を尊重してください。 リポジトリに AGENTS.md ／ CLAUDE.md ／ HERMES.md やリンター設定がある場合は、そのルールをレビュアーへのプロンプトに含めて、提案がプロジェクトのスタイルに沿うようにしてください。
• 差分が大きいとコンテキストを圧迫します。 差分が非常に大きい場合は、委任する前に範囲を絞ってください。5,000行の差分を持つサブエージェントが4つあるとコストがかかり、途中で切り詰められる可能性もあります。
• 不要コード検出ツールを過信しないでください。 knip、ts-prune、depcheck は、動的に使用されているエクスポート（文字列ベースのインポートやリフレクション）にもフラグを立てます。削除する前に、必ずシンボル名を grep で検索してください。ツールの報告に問題がないことは、使用されていない証拠にはなりません。
• 公開インターフェースを確認せずに名前を変更しないでください。 エクスポート名、API ルートのパス、DB カラム名、設定キーは、名前が不適切であっても利用者との契約です。変更すれば利用者に影響します。公開インターフェースに関わる変更には RISKY とタグ付けし、自動で名前を変更してはいけません。
• 「不要な」エラー処理を削除しないでください。 空の catch ブロックや無視されるエラーには意図がある場合があります。その状況ではエラーが想定内で無害なのかもしれません。削除せずに指摘し、判断は人に委ねてください。
• 特殊なケースがすべてその場しのぎとは限りません。 互換性シム、段階的な移行、ベンダーコードを囲む隔離レイヤーは、高度に関する違反に見えても、意図的な設計である場合があります。指摘する前に git blame と周辺のコメントを確認してください。意図が不明な場合は、confidence: low としてください。

関連項目

インストール環境に subagent-driven-development スキル（任意）がある場合は、タスクごとに実装 中 に並行レビューを行う、補完的なケースを扱います。このスキルは、作業完了後に単独で行う整理の工程です。コミット前のセキュリティ／品質チェックには requesting-code-review を使用してください。そちらはバグ探しであり、こちらは整理です。