/tdd-refactor

description: TDDのRefactorフェーズを実行します。テストを通す実装が完了した後、コード品質の改善とリファクタリングを行います。
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite
argument-hint: "[要件名] [TASK-ID]"

TDDのRefactorフェーズを実行し、Greenフェーズで作成した実装コードの品質を改善します。

context

出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} 信頼性評価=[] メモファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md テストケースファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md Greenフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-green-phase.md Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md

step

• $ARGUMENTS がない場合、「引数に要件名とTASK-IDを指定してください(例: ユーザー認証機能 TASK-0001)」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2: コンテキスト準備

開発コンテキストの準備を実行する:

1. **タスクノートの読み込み（唯一のコンテキストソース）**

• `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み
• 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成
• note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み

2. **直前フェーズの出力を読み込み**

• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - テストケース定義
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-green-phase.md` - Greenフェーズの実装記録
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md` - 既存のRefactorフェーズ記録（存在する場合）
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 開発履歴メモ（存在する場合）

読み込み完了後、step3 を実行する

step3: テスト実行とコード品質確認

• **現在のテストが全て通ることを確認**
• 【品質保証】: リファクタ前の動作確認
• 【安全性確保】: 変更による機能破綻の防止
• 【実行方法】: Taskツールを使用してテストを実行し、結果を詳細に分析

• **テスト実行時間のチェック**
• 【長時間テストの検出】: 2秒以上かかるテストがないか確認
• 【警告表示】: 遅いテストが見つかった場合は以下を表示

    ⚠️ 遅いテストが検出されました（2秒以上）

    詳細な分析とリファクタリング提案が必要な場合:
    `/tsumiki:dcs:test-performance-analysis` を実行してください

    テスト実行速度の改善パターン:
    `/tsumiki:test-optimization-patterns` を実行してください

• **コード・テスト除外チェック**
• 【.gitignore確認】: 本来確認対象のコードファイルが除外されていないかチェック
• 【テスト除外確認】: `describe.skip`, `it.skip`, `test.skip`等でテストが無効化されていないかチェック
• 【jest設定確認】: `jest.config.js`や`package.json`の`testPathIgnorePatterns`等でテストファイルが除外されていないかチェック
• 【実行対象確認】: 実際に実行されるべきテストとコードが適切に対象に含まれているかチェック

• **開発時生成ファイルのクリーンアップ**
• 【不要ファイル検出】: 開発中に作成された一時的なファイルを検出・削除
• 【対象ファイルパターン】: 以下のパターンに該当するファイルを確認
• `debug-*.js`, `debug-*.ts`: デバッグ用スクリプト
• `test-*.js`, `test-*.ts`, `temp-*.js`: 一時テストファイル
• `*.tmp`, `*.temp`, `*.bak`, `*.orig`: 一時・バックアップファイル
• `*~`, `.DS_Store`: エディタ・システム生成ファイル
• `test-output-*`, `*.test-output`: テスト出力ファイル
• 【安全確認】: 削除前に各ファイルの内容を確認し、重要なコードが含まれていないかチェック
• 【選択的削除】: 不要と判断されたファイルのみを削除し、必要なファイルは保持
• 【削除ログ】: 削除したファイルと削除理由をログとして記録
• 【実行手順】:

1. `find . -name "debug-*" -o -name "test-*" -o -name "temp-*" -o -name "*.tmp" -o -name "*.temp" -o -name "*.bak" -o -name "*.orig" -o -name "*~" -o -name ".DS_Store" | grep -v node_modules` でファイル検出 2. 各ファイルの内容をReadツールで確認 3. 不要と判断されたファイルは削除し、削除理由を記録

• step4 を実行する

step4: レビューと改善計画

• **セキュリティレビューの実施**
• 【脆弱性検査】: コード全体のセキュリティホールの特定
• 【入力検証確認】: 不正な入力値に対する防御機能の確認
• 【セキュリティガイドライン適用】: 業界標準のセキュリティベストプラクティスの適用
• レビュー結果を文書化

• **パフォーマンスレビューの実施**
• 【計算量解析】: アルゴリズムの時間計算量・空間計算量の評価
• 【ボトルネック特定】: 処理速度やメモリ使用量の問題箇所の特定
• 【最適化戦略】: 具体的なパフォーマンス改善施策の立案
• レビュー結果を文書化

• **改善計画の作成**
• <refactoring_guidelines> を参考に改善計画を立てる
• 各改善項目に信頼性レベル(🔵🟡🔴)を付与
• 改善の優先順位を決定

• step5 を実行する

step5: リファクタリング実行

• **小さな改善を1つずつ適用**
• 【段階的改善】: 影響範囲を限定した安全な変更
• 【トレーサビリティ】: 変更内容の追跡可能性確保
• <refactoring_guidelines> の各観点に従って改善を実施
• <comment_template> に従って日本語コメントを強化

• **各改善後にテストを実行**
• 【継続的検証】: 改善の度に動作確認
• 【早期発見】: 問題の早期発見と修正
• 【選択的実行】: 変更したファイルに関連するテストのみを実行（高速）
• Jest: `npm test -- --findRelatedTests <変更ファイル>`
• pytest: `pytest <関連テストファイル>`
• 特定のテストスイート: `npm test -- <テストパターン>`
• **注意**: 全体のテスト実行は verify-complete フェーズで実施

• **テストが失敗したら即座に戻す**
• 【迅速復旧】: 問題発生時の素早い対応
• 【安定性維持】: システムの安定した状態を保持

• リファクタリング内容について、品質判定基準に基づいて以下を評価:
• テスト成功状況
• セキュリティ品質
• パフォーマンス品質
• コード品質の向上度
• ファイルサイズ(500行制限)
• 日本語コメントの品質

• 品質判定結果をユーザーに表示する
• step6 を実行する

step6: ドキュメント更新

• **Refactor-phaseファイルの作成・更新**:
• リファクタリング内容と設計改善を {{Refactorフェーズファイル}} に保存
• 既存ファイルがある場合は追記
• 以下の内容を記録:
• 改善されたコードの全文
• 改善ポイントの説明
• セキュリティレビュー結果
• パフォーマンスレビュー結果
• テスト実行結果
• コメント改善内容

• **メモファイルの最終更新**:
• {{メモファイル}} のRefactorフェーズセクションと概要を更新
• 既存のメモファイルがない場合は新規作成(TDDメモファイル形式に従う)
• 以下の内容を記録:
• リファクタリング日時
• 改善内容
• セキュリティレビュー結果
• パフォーマンスレビュー結果
• 最終コード
• 品質評価
• 概要セクションの現在のフェーズを「完了」に更新

• step7 を実行する

step7: TODO更新と完了判定

• TodoWrite ツールで TODO ステータスを更新する
• 現在のTODO「Refactorフェーズ(品質改善)」を「completed」にマーク
• リファクタリングフェーズの完了をTODO内容に反映
• 品質判定結果をTODO内容に記録
• 次のフェーズ「完全性検証」をTODOに追加
• 改善が必要な箇所がある場合は新たなTODOとして追加

• **品質判定**: リファクタリング成果の品質を以下の基準で判定
• テスト結果: 全てのテストが引き続き成功
• セキュリティ: 重大な脆弱性が発見されていない
• パフォーマンス: 重大な性能課題が発見されていない
• リファクタ品質: 目標が達成されている
• コード品質: 適切なレベルに向上

• **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示
• 「次のお勧めステップ: `/tsumiki-legacy:tdd-verify-complete` で完全性検証を実行します。」

rules

リファクタリングの原則

• **機能的な変更は行わない**(新機能追加はNG)
• **テストが通らなくなったら即座に修正**
• **一度に大きな変更をしない**
• **日本語コメントの品質も向上させる**
• **品質確認のためのテスト実行時はTaskツールを利用する**

禁止事項(NEVER)

• 実装コード内でのモック・スタブの記述
• 実装コード内でDBに代わるインメモリーストレージの利用

ファイルサイズ管理

• **500行制限**: ファイルサイズが500行未満になるよう分割・最適化
• **長大なファイルの機能別分割**
• **適切なモジュール境界の設定**

信頼性レベル指示

リファクタリング時には、各改善内容について元の資料との照合状況を以下の信号でコメントしてください:

• 🔵 **青信号**: 元の資料を参考にしてほぼ推測していない場合
• 🟡 **黄信号**: 元の資料から妥当な推測の場合
• 🔴 **赤信号**: 元の資料にない推測の場合

品質判定基準

✅ 高品質:
- テスト結果: Taskツールによる実行で全て継続成功
- セキュリティ: 重大な脆弱性なし
- パフォーマンス: 重大な性能課題なし
- リファクタ品質: 目標達成
- コード品質: 適切なレベル
- ドキュメント: 完成

⚠️ 要改善:
- テストの一部失敗(Taskツールで検出)
- セキュリティ脆弱性発見
- パフォーマンス課題発見
- リファクタ目標未達成
- 品質改善不十分
- ドキュメント不備

ファイルパスの記載ルール

• **プロジェクトルートを基準とした相対パスを使用する**
• フルパス(絶対パス)は記載しない
• 例:
• ❌ `/Users/username/projects/mya