---
name: refactoring
description: >
  コードのリファクタリングを支援するスキル。外部仕様（振る舞い）を変更せずに、コードの内部構造を改善する。
  以下のリクエストに使用：
  - 関数・クラスの分割・整理
  - 変数名・関数名のリネーム
  - 重複コードの排除・共通化
  - 設計パターンの適用
  - コードの可読性・保守性の向上
  - 「リファクタリングして」「きれいにして」「整理して」「DRYにして」などの指示
  対応言語：言語問わず汎用。テストが不十分な場合はリファクタリングを中止する。
---

# Refactoring Skill

リファクタリングの定義・制約・禁止事項は [references/definition.md](references/definition.md) を参照。

## ワークフロー

### 1. スコープレベルの確認

明示指示がない場合は **Level 1**（デフォルト）で進める。

| Level | 範囲 | 必要な明示指示 |
|-------|------|----------------|
| 1 | 関数内 / 1ファイル内 | 不要（デフォルト） |
| 2 | 複数ファイル / 依存関係の整理 | 必要 |
| 3 | アーキテクチャ変更 | 必要 |

### 2. リファクタリング候補の特定

対象が明示されていない場合に実施。「直す価値が高く」「範囲が限定でき」「テストで守れる」箇所を候補化する。

**多段フィルタ:**
1. 静的指標で候補抽出（複雑性/サイズ/重複/依存/型・境界）
2. 動的指標で優先度付け（churn/バグ修正頻度/レビュー摩擦/障害起因）
3. 候補を最小単位（関数/メソッド）に分割してメタデータ化
4. 上位N件を提案し、次のGate判定へ進む

**提案フォーマット（上位N件）:**

| 対象（ファイル:行 / 関数名） | 根拠（指標値） | 期待効果 | 影響範囲 | Gate B 材料 |
|---|---|---|---|---|
| `foo.ts:42 / parseUser` | 循環複雑度 12 | 可読性向上 | 呼び出し元3箇所 | 正常系のみカバー |

### 3. 振る舞い保持の検証（実行前 Gate チェック）

リファクタリングを実行する前に、以下の2つの Gate を確認する。

**Gate A（必須条件）**: 既存の自動テストがすべて成功すること。

**Gate B（十分性チェック）**: 変更対象の重要パスがテストされていること：
- 正常系（代表入力）
- 境界値（空/0/最大長/上限付近）
- 異常系（例外・エラー条件）
- 副作用（DB更新・外部I/O・キャッシュなど）

**Gate A と Gate B を両方満たす場合のみ、リファクタリングを実行する。**

いずれかが未達の場合は**リファクタリングを中止**し、以下を実施する：

**出力（ユーザーへ）:**
1. 未達の条件（A/B のどれか）
2. 根拠（カバレッジ値、未テストの重要パスの具体）
3. 実行しない理由（仕様保持を客観的に担保できないため）
4. 推奨対応（追加すべきテストの概要）

**記録（ファイルへ）:** プロジェクトルートの `refactoring-aborted.md` に追記する。ファイルが存在しない場合は新規作成し、先頭に `# リファクタリング中止ログ` ヘッダーを付ける。

```markdown
## YYYY-MM-DD | `<対象ファイル:行>` / `<関数名>`

- **未達Gate**: A / B（該当するもの）
- **根拠**: <カバレッジ値・未テストパスの具体>
- **推奨対応**: <追加すべきテストの概要>
```

### 3.5 テスト追加後の再開フロー

ユーザーがテストを追加してリファクタリングの再実行を依頼した場合：

1. Gate A・B を再チェックする
2. **両方通過した場合**: Step 4 へ進む（リファクタリング完了後に Step 5 でエントリーを削除する）
3. **まだ未達の場合**: 残る未達条件と追加対応を案内し、`refactoring-aborted.md` の該当エントリーの「推奨対応」を更新する

### 4. リファクタリングの実施

Gate を通過したら、以下を守りながら実施する：

- **変更は最小限・段階的に行う**
- 禁止事項（[references/definition.md](references/definition.md) 参照）を守る

### 5. 完了の確認

以下の成功条件をすべて満たすことを確認する：
1. 振る舞いが変更されていない（テストが通る）
2. コードの理解しやすさが向上している
3. 変更の影響範囲が限定されている
4. 不要な複雑性が減少している

確認後、`refactoring-aborted.md` に対象のエントリー（`## YYYY-MM-DD | \`<対象ファイル:行>\` / \`<関数名>\`` で始まるブロック）が存在する場合は**そのエントリーを削除する**。ファイルがヘッダー行のみになった場合はファイルごと削除してよい。

### 6. 変更内容のサマリ出力

完了後、以下を簡潔に報告する：
- 実施したリファクタリングの種類と箇所
- 改善した点（可読性・重複排除など）
- テスト結果（Gate A/B の確認結果）