simplify

Simplify

意図した動作を変えずに、変更したコードを改善するには、このスキルを使用します。これは、4つの観点から確認する /simplify ワークフローを、独自に作成したリポジトリ標準の手法に置き換えたものです。

/simplify -> 4 cleanup agents in parallel -> apply the fixes

特定の Claude Code パッケージバージョンとの完全な一致を主張するものではなく、Anthropic のプロンプト文を再現するものでもありません。公式 npm パッケージは、バージョンとパッケージのメタデータを確認する目的でのみ使用しています。コンパイル済みの内容はプロプライエタリであり、読めるプロンプトのソースとして扱ったり、再配布したりしていません。来歴は、2026-09-16 にそのメタデータと、コミット c10ea52363b3fce1ebfc355565412711e9e82bc1 時点の、内容を閲覧できる二次資料である Piebald の参照情報を使って確認しました。その参照情報によると、4つの観点から確認する形式は Claude Code 2.1.154 で導入されており、ワークフローの動作は v2.1.273 のスナップショットまで変わっていません。

これは正しさのバグを探すためのものではありません。再利用、簡素化、効率、抽象化の深さを確認してください。バグの発見は、コードレビューやデバッグのワークフローに任せてください。

使い方

/simplify                         # Review the current diff
/simplify HEAD~3                  # Review changes from HEAD~3 to HEAD
/simplify main                    # Review changes against main
/simplify path/to/file.ts         # Review an explicit file target
/simplify 123                     # Review an explicit PR target when supported
/simplify focus on error handling # Keep the same flow, with added focus

フェーズ 0 - 差分を集める

集めた差分をレビュー対象とします。

1. ユーザーが PR 番号、ブランチ名、またはファイルパスを指定した場合は、既定の範囲を推測せず、指定された対象をレビューします。
2. 指定がない場合は、git diff @{upstream}...HEAD を優先します。
3. upstream がない場合は、git diff main...HEAD、次に git diff HEAD~1 を使用します。
4. 未コミットの変更がある場合、または選択した範囲の差分が空の場合は、git diff HEAD も実行し、作業ツリーの変更を含めます。このレビューは、次のコミット前に実行されることがよくあります。
5. すべての差分コマンドの結果が空の場合は、ユーザーが明示的に指定したファイル、または現在のセッション中に以前変更されたファイルのみをレビューします。それでも対象がない場合は、簡素化する変更コードがないことを伝えます。

対象範囲は狭く保ちます。ユーザーからより広範なクリーンアップを求められない限り、無関係なファイルにまで範囲を広げないでください。

フェーズ 1 - レビュー

プラットフォームが並列エージェントに対応している場合は、独立した4つのレビューレージェントを1つのメッセージで起動します。すべてのエージェントに同じ差分を渡し、それぞれに1つだけレビュー観点を指定してください。並列で委任できない場合は、指摘事項を観点ごとに分けて、同じ4つのレビューを自分で実施します。

各指摘には、file、line、1行の summary、および具体的なコスト、つまり重複しているもの、無駄になっているもの、または保守しにくくなっているものを含める必要があります。

再利用

コードベースにすでにある機能を再実装している新しいコードを指摘します。共有モジュールやユーティリティモジュール、変更箇所に隣接するファイルを検索し、代わりに使用する既存のヘルパー、型、コンポーネント、定数、またはパターンを具体的に示してください。

簡素化

差分で追加された不要な複雑さを指摘します。冗長な状態や導出可能な状態、わずかに異なるだけのコピー＆ペースト、深いネスト、残されたデッドコード、実際の動作に見合わない複雑な制御フローなどが該当します。同じ役割を果たす、よりシンプルな形式を具体的に示してください。

効率

差分によって追加された無駄な処理を指摘します。冗長な計算、繰り返される I/O、順次実行されている独立した処理、起動時やホットパスに追加されたブロッキング処理などが該当します。また、クロージャーやキャプチャした環境から構築され、オブジェクトの存続期間中にそれらを保持し続ける長寿命オブジェクトも指摘してください。必要なフィールドだけをコピーするクラス、構造体、または単純なデータオブジェクトを優先します。より低コストな代替案を具体的に示してください。

抽象化の深さ

各変更が、脆弱な応急処置ではなく、適切な深さで実装されているかを確認します。共有インフラに特殊ケースを重ねている場合は、修正が根本に届いていない可能性があります。個別の分岐を追加するのではなく、基盤となる仕組みを一般化してください。

フェーズ 2 - 修正を適用する

4 件すべてのレビューが完了するまで待ちます。その後、同じ行や仕組みを指摘する内容を重複排除し、残った確度の高い問題をそれぞれ直接修正します。

修正によって意図した動作が変わる場合、レビュー対象の差分を大きく越える変更が必要な場合、または誤検出と思われる場合は、その指摘をスキップします。指摘に反論するのではなく、スキップした理由を簡潔に記します。

ユーザーが動作の変更を明示的に依頼していない限り、動作、公開 API、テスト、ユーザーに表示される出力を維持します。

検証

変更したファイルに対して、関連する最小限の検証を実行します。対象を絞ったテスト、リンター、型チェック、または目的を絞ったビルドなどです。有用な検証がない場合や、現時点で実行するにはコストがかかりすぎる場合は、実行しなかった内容を正確に伝えます。

報告

最後に、次の内容を簡潔にまとめます。

• 修正した内容。
• スキップした指摘とその理由。
• 実際に残っているリスクや、今後の対応。

対応可能な指摘がなかった場合は、変更したコードは 4 つの簡素化の観点ですでに問題がなかったと伝えます。

ガードレール

• まずリポジトリの指示とローカルのパターンに従います。
• 大規模なリファクタリングより、小さく元に戻しやすい変更を優先します。
• 明示的なコードを、巧妙または魔法のようなコードに変えません。
• スタイルだけを変えるための不要な変更はしません。
• 簡素化によってコードのデバッグが難しくなる場合は、明確なコードを維持します。