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つだけ）