# Code Simplifier

> 変更されたコードを再利用性・品質・効率の観点で分析し、問題を直接修正するスキル。「コードをシンプルにして」「リファクタして」「コードを整理して」「簡潔にして」「DRYにして」「重複を除去して」「効率化して」「コードを改善して」「設計を整理して」「クラスを分割して」「コードスメルを除去して」「デザインパターンを適用して」などのリクエストで発動する。レポートを出力するだけでなく、コードを直接修正する。

- Skill: `ynitto/code-simplifier` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ynitto/code-simplifier`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ynitto/code-simplifier/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ynitto (https://skillmd.com/u/ynitto)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ynitto/code-simplifier

---


# 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](references/techniques.md) を参照。

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

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

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

### Step 4: コードを修正する

各変更のサイクル:

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

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

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

```
## code-simplifier 結果

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

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

---

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

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