---

name: tdd-refactor description: TDDのリファクタ(REFACTOR)フェーズを厳密に実行する。全テストGREENを維持したまま、重複排除・命名改善・関心分離など内部構造を改善する。仕様変更が必要なら先にSpecとテスト期待値を更新してから実装を調整する。

tdd-refactor（リファクタリング：設計と表現を改善する）

このスキルの目的

• テストがGREENの安全網で、コード/テスト/仕様表現を改善する。
• “変更容易性”を上げるために、内部構造の負債を計画的に返す。

前提（満たさない場合は停止）

• 全テストがGREENである（直前に確認済み）。
• 変更は「仕様変更」ではなく「内部改善」である。
  • もし仕様変更が必要なら：ユーザーの了承のもと先にSpecとテスト期待値を更新してから（＝別のREDとして扱う）。

必ず取り組むべき内容

• 変更範囲にRustコードが含まれる場合
  • cargo fixでの機械的な修正
  • cargo fmt -allでのフォーマット
  • cargo clippy --workspace --all-targets --all-features -- -D warningsで指摘された内容の修正
• 変更範囲にMarkdown文書が含まれる場合
  • markdownlint-cli2 --fixでの機械的な修正

手順（厳守）

1. フェーズ宣言
   • Current Phase: REFACTOR
2. リファクタ対象を限定（やりすぎ防止）
   • 直前のGREENで記録したTODO（最大3つ）から着手順を決める。
3. 小さく刻んで改善 → すぐテスト
   • 変更は小さく、意図が説明できる単位で行う。
   • 1〜3ステップごとにテストを実行し、常にGREENを維持する。
4. 対象例（必要に応じて）
   • 重複排除（DRY）、命名改善、責務分離（SoC）、副作用の分離、複雑条件の単純化、不要依存の縮小
   • テストコード側も対象：振る舞いベースに寄せ、実装に引きずられたテストを減らす（ただし期待値＝振る舞いは変えない）
5. Spec表現の改善（必要な範囲で）
   • Spec-IDとテストの対応が読み取れる状態を保つ（トレーサビリティ維持）。

ガードレール（やってはいけない）

• 期待値（振る舞い）を変える変更を“リファクタ”と呼んで混ぜない。
• 大規模な再設計を始めない（別PR/別Specに分割）。
• 選択肢を大量に提示して議論を増やさない。デフォルト案で進め、例外のみ明示する。

出力フォーマット（返答はこれに従う）

1. Current Phase: REFACTOR
2. リファクタの目的:
3. 実施内容:（箇条書き。どの改善を何のために行ったか）
4. 影響範囲:（主要ファイルパス）
5. 実行コマンド:（実際に走らせたコマンド）
6. 結果:（全テストGREENの要約）
7. 次:（次のRED候補があればSpec-IDレベルで1つだけ）