Refactoring Skill

リファクタリングの定義・制約・禁止事項は 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 に追記する。ファイルが存在しない場合は新規作成し、先頭に # リファクタリング中止ログ ヘッダーを付ける。

## 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 参照）を守る

5. 完了の確認

以下の成功条件をすべて満たすことを確認する：

1. 振る舞いが変更されていない（テストが通る）
2. コードの理解しやすさが向上している
3. 変更の影響範囲が限定されている
4. 不要な複雑性が減少している

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

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

完了後、以下を簡潔に報告する：

• 実施したリファクタリングの種類と箇所
• 改善した点（可読性・重複排除など）
• テスト結果（Gate A/B の確認結果）