code-simplifier

name	code-simplifier
description	変更されたコードを再利用性・品質・効率の観点で分析し、問題を直接修正するスキル。「コードをシンプルにして」「リファクタして」「コードを整理して」「簡潔にして」「DRYにして」「重複を除去して」「効率化して」「コードを改善して」「設計を整理して」「クラスを分割して」「コードスメルを除去して」「デザインパターンを適用して」などのリクエストで発動する。レポートを出力するだけでなく、コードを直接修正する。
metadata	{"version":"2.0.0","tier":"experimental","category":"review","tags":["refactoring","code-quality","dry","design-patterns","clean-code"]}

code-simplifier

変更されたコードを再利用性・品質・効率の観点で分析し、問題を直接修正する。

原則

• 動作を変えない — リファクタリングは振る舞いを保つ。バグ修正や機能追加は行わない
• 変更点に集中する — diff がある部分を中心に、スコープを広げすぎない
• 小さく確実に — 一度に一つの変更、テストが通ったらコミットする
• 説明してから修正する — 何をなぜ変えるかを一言添えてから修正する

スコープ境界

対象	可否
内部実装の整理・分割・命名改善	✅ する
公開 API のシグネチャ変更	⚠️ ユーザー承認を得てから行う
バグ修正・機能追加	❌ しない（別タスクにする）
テスト未整備のコードへの大規模変更	❌ しない（先にテストを追加する）

---

ファストパス（単純な修正）

以下に該当する場合はワークフローを省略し、直接実施してサマリーを出す:

• 変数・関数の改名のみ
• コメントアウトされたコードの削除
• マジックナンバーの定数化
• 明らかに使われていないコードの削除

該当しない場合は以下のワークフローを使う。

---

ワークフロー

Step 1: 対象コードを特定する

1. ユーザーが対象ファイル・範囲を指定している場合はそれを使う
2. 指定がない場合は git diff --name-only HEAD で変更ファイルを確認する
3. 対象ファイルを読んで全体像と既存のテストを把握する
4. テストがない場合はリファクタリング前にテスト追加を提案し、ユーザーの承認を得てから Step 2 へ進む

Step 2: 3つの観点で分析する

再利用性（Reuse）

• 重複したロジック・コードブロックがある → 関数・定数・ユーティリティに抽出する
• 同じ処理が複数箇所に散在している → 共通化できるか判断する
• 既存のユーティリティ・ライブラリで代替できる処理がある

品質（Quality）

• 変数名・関数名が意図を反映していない → 改名する
• 関数が複数の責務を持っている（目安: 50行超） → 分割する
• マジックナンバー・ハードコード値がある → 定数化する
• 深いネスト・複雑な条件分岐がある → 早期リターンやガード節で平坦化する
• クラスが肥大化している（神クラス） → 単一責務原則で分割する
• 関数のパラメータが多い（5個以上） → パラメータオブジェクトに変換する

効率（Efficiency）

• 不要な計算・変数・処理がある → 削除する
• ループ内で毎回同じ計算をしている → ループ外に移動する
• 冗長な条件式・型変換がある → 簡潔な表現に置き換える
• 不要な中間変数がある → インライン化する

手法のコード例は references/techniques.md を参照。

Step 3: 修正の優先順位を決める

優先度	基準
高	50行超の関数・深いネスト・重複コード（理解・変更を直接阻害する）
中	神クラス・関数分割・命名改善・定数化
低	スタイルの統一、微細なリファクタリング

スコープを守る: 変更範囲に関連するコードのみを修正する。複数箇所の修正が必要な場合は計画を説明してからユーザーに確認を取る。公開 API の変更を含む場合は必ず明示する。

Step 4: コードを修正する

各変更のサイクル:

テスト実行（緑を確認）→ 1つの変更を実施 → テスト実行 → 全テスト通過後にコミット

• 修正内容を1行で説明してから実施する（例: 「重複した検証ロジックをvalidateInput関数に抽出します」）
• 一度に複数の問題を修正しない
• テストが通らない場合はすぐに差し戻してから原因を調査する

Step 5: 修正内容をサマリーする

## code-simplifier 結果

### 実施した修正
- [修正内容]: <何をどう変えたか>

### 修正しなかった点（該当あれば）
- <修正を見送った理由>

---

チェックリスト（完了確認）

• 全テストがリファクタリング前後で通っている
• 公開 API を変更した場合はユーザーの承認を得た
• 機能追加・バグ修正をリファクタリングと混在させていない