mcpField
S
simplify-code

simplify-code

github.com/sickn33開発48.8k57 回インストール今日更新
リポジトリ

simplify-code について

変更コードを再利用性、品質、効率、明瞭さの観点で確認し、動作を保つ修正も選択できるCodexスキルです。範囲を絞ったコードレビューやリファクタリング向けに、レビュー、修正、検証のモードを備えます。

主な機能

  1. 014つの観点でコードをレビュー
  2. 02差分やパスで対象範囲を指定
  3. 03許可時にCodexサブエージェントを並列利用
  4. 04確度の高い安全な修正を適用
  5. 05必要に応じて対象を絞って検証
  6. 06指摘事項と変更内容を要約

活用シーン

  1. 01ブランチの変更コードをレビュー
  2. 02限定した差分の重複を特定
  3. 03リファクタリングを安全に簡素化
  4. 04対象を絞ったテストで修正を検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill simplify-code

インストール後、Claude Code で/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 つの観点でレビューする

現在のユーザーまたはリポジトリの指示で委任が明示的に許可されている場合に限り、サブエージェントを起動します。それ以外の場合は、4 つの観点でローカルにレビューします。エージェントの役割名はホストによって異なります。ユーザーが選択したモデルを変更したり、許可なくコードを外部のレビュアーに開示したりしないでください。

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

サブエージェントを起動する場合:

  • 各サブエージェントに同じ対象範囲を指定します
  • 割り当てられたレビュー役割だけを調査するよう伝えます
  • 簡潔で構造化された指摘のみを報告するよう依頼します
  • ファイル、行またはシンボル、問題、推奨する修正、確信度を報告するよう依頼します

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: 結果の要約

最後に簡潔な結果を述べます:

  • 何がレビューされたか
  • 何が修正されたか(修正があれば)
  • 何が意図的にそのままにされたか
  • 検証が実行されたかどうか

このルーブリックに対してコードがすでにクリーンである場合は、編集を捏造するのではなく、そのことを直接述べてください。

例

ユーザーのリクエスト:

動作を維持したまま変更されたコードを単純化し、その後、リファクタリングが安全であることを証明するために的を絞ったテストを実行してください。

制限事項

  • このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
  • 出力を、環境固有の検証、テスト、または専門家によるレビューの代替として扱わないでください。
  • 必要な入力、権限、安全境界、または成功基準が欠けている場合は、停止して明確化を求めてください。

コメント