/tdd-red

description: TDDのRedフェーズを実行します。失敗するテストケースを作成し、実装すべき機能を明確に定義します。
allowed-tools: Read, Glob, Grep, Task, Write, TodoWrite, Edit
argument-hint: "[要件名] [TASK-ID]"

TDDのRedフェーズを実行します。失敗するテストケースを作成し、実装すべき機能を明確に定義します。

context

出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} 対象テストケース={{test_case_name}} テストケース追加目標数=10以上 信頼性評価=[] 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md テストケース定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md Redフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-red-phase.md メモファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md タスクノートファイル=./docs/implements/{要件名}/{{task_id}}/note.md

step

• $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}-red-phase.md` - 既存のRedフェーズ記録（存在する場合）
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 開発履歴メモ（存在する場合）

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

step3

• <red_phase_template> の内容を context の情報で埋めて、テストコードを作成する
• 読み込んだコンテキスト情報（タスクノート、追加ルール等）を活用
• 信頼性レベル（🔵🟡🔴）を各テストケースに記載
• 対象テストケース名が指定されている場合は、そのテストケースのみ実装
• 指定がない場合は、未実装のテストケースから10個以上を選択して実装
• Write ツールを使用してテストファイルに保存
• Bash ツールを使用して**新規作成したテストファイルのみ**を実行し、失敗することを確認
• Jest: `npm test -- <作成したテストファイル>`
• Playwright: `npx playwright test <作成したテストファイル>`
• pytest: `pytest <作成したテストファイル>`
• 全テスト実行は不要（verify-completeフェーズで実施）

• 作成したテストコードについて、品質判定基準に基づいて以下を評価：
• テスト実行: 実行可能で失敗することを確認済み
• 期待値: 明確で具体的
• アサーション: 適切
• 実装方針: 明確
• 信頼性レベル（🔵🟡🔴の分布）

• 品質判定結果に応じた処理:
• **✅ 高品質**: そのまま step4 へ
• **⚠️ 要改善**: 自動修正ループを実施

1. 要改善の指摘内容（どの項目が不足/不適切か）を特定 2. Task tool (subagent_type: general-purpose) で指摘内容を渡してテストコードを修正させる 3. 修正後のテストコードを Write tool で上書き保存 4. Bash tool で修正後のテストファイルを再実行し、失敗することを再確認 5. 再度品質判定基準に基づいて評価 6. 高品質になれば step4 へ 7. まだ要改善の場合: もう1回だけ修正を試みる（最大2回まで） 8. 2回修正しても要改善のまま → 警告をtasknoteの注意事項に追記し、step4 へ

• **⚠️ テストが成功してしまった場合**（Redフェーズなのに失敗しない）:

1. テストの期待値やアサーションを見直すsubagent（general-purpose）を起動 2. 「まだ実装されていない機能をテストする」という原則に基づいて修正 3. 修正後に再実行し、失敗することを確認 4. 最大2回まで修正を試みる 5. 2回修正しても成功してしまう → AskUserQuestion でユーザに確認

• step4 を実行する

step4: ドキュメント更新

• **Red-phaseファイルの作成・更新**：
• テストコードと設計内容を {{Redフェーズファイル}} に保存
• 既存ファイルがある場合は追記
• 以下の内容を記録：
• 作成したテストケースの一覧
• テストコードの全文
• 期待される失敗内容
• Greenフェーズで実装すべき内容

• **メモファイルの作成・更新**：
• {{メモファイル}} にRedフェーズの内容を作成または追記
• 既存のメモファイルがある場合は、Redフェーズセクションを更新
• メモファイルが存在しない場合は新規作成（TDDメモファイル形式に従う）
• 以下の内容を記録：
• 作成日時
• テストケースの概要
• テストコード
• 期待される失敗
• 次のフェーズへの要求事項

• step5 を実行する

step5: TODO更新と次ステップ

• TodoWrite ツールで TODO ステータスを更新する
• 現在のTODO「Redフェーズ（失敗テスト作成）」を「completed」にマーク
• 失敗テスト作成フェーズの完了をTODO内容に反映
• 品質判定結果をTODO内容に記録
• 次のフェーズ「Greenフェーズ（最小実装）」をTODOに追加

• 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:tdd-green` でGreenフェーズ（最小実装）を開始します。」

rules

ファイル名のルール

出力ファイルのパス形式

• テストファイル: プロジェクトの技術スタックに応じた適切なディレクトリ
• 例: `tests/unit/{feature_name}.test.js`
• 例: `tests/e2e/{feature_name}.spec.js`
• メモファイル: `docs/implements/{要件名}/{task_id}/{feature_name}-memo.md`
• Redフェーズ記録: `docs/implements/{要件名}/{task_id}/{feature_name}-red-phase.md`

ファイル名の命名規則

• 機能名を簡潔な英語に変換する
• ケバブケース（kebab-case）を使用
• 最大50文字程度に収める
• 例:
• "ユーザー認証機能" → "user-auth"
• "データエクスポート機能" → "data-export"
• "パスワードリセット機能" → "password-reset"

テストケース追加目標数

**テストケース追加目標数**: 10以上（利用可能なテストケースが10未満の場合は全て追加）

未実装のテストケースから10個以上のテストケースを選択して実装してください。利用可能なテストケースが10個未満の場合は、利用可能な全てのテストケースを実装対象とします。 既にテストケースが実装済みの場合はテストケース定義に書かれているテストケースからテストを追加します。 要件網羅率と機能網羅率を高めるテストケースを追加してください NEVER テストケースの最大行数を500行を目標に分割してください

信頼性レベル指示

テストコード作成時には、各テストケースの内容について元の資料との照合状況を以下の信号でコメントしてください：

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

品質判定基準

✅ 高品質:
- テスト実行: 成功（失敗することを確認）
- 期待値: 明確で具体的
- アサーション: 適切
- 実装方針: 明確
- 信頼性レベル: 🔵（青信号）が多い

⚠️ 要改善:
- テストが実行できない
- 期待値が曖昧
- 実装アプローチが不明
- 複雑なテストケース
- 信頼性レベル: 🟡🔴（黄・赤信号）が多い

TODO更新パターン

- 現在のTODO「Redフェーズ（失敗テスト作成）」を「completed」にマーク
- 失敗テスト作成フェーズの完了をTODO内容に反映
- 品質判定結果をTODO内容に記録
- 次のフェーズ「Greenフェーズ（最小実装）」をTODOに追加

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

• **プロジェクトルートを基準とした相対パスを使用する**
• フルパス（絶対パス）は記載しない
• 例:
• ❌ `/Users/username/projects/myapp/src/utils/helper.ts`
• ✅ `src/utils/helper.ts`

🎯 UI開発タスクでの**E2Eテスト優先**方針

**UIコンポーネントや画面機能の開発タスクでは、E2Eテスト（特にPlaywright）を最優先で活用してください：**

🚀 E2Eテストを**必須**とすべきケース

• **ユーザーインターフェースの動作確認** - UIコンポーネントの表示・非表示、状態変更
• **画面遷移やナビゲーションの検証** - ページ間の移動、ルーティングの動作
• **フォーム入力と送信機能のテスト** - 入力検証、エラー処理、送信後の動作
• **ユーザーインタラクション** - クリック、入力、スクロール、ドラッグ＆ドロップ等
• **ブラウザ固有の動作確認** - 異なるブラウザでの互換性テスト
• **レスポンシブデザインの検証** - 画面サイズによるレイアウト変更
• **アクセシビリティの確認** - キーボード操作、スクリーンリーダー対応
• **パフォーマンスの確認** - 読み込み時間、レンダリング速度

🥇 **Playwright強力推奨**フレームワーク

**UIタスクでは原則としてPlaywrightを使用してください：**

1. **Playwright** (🎯最優先推奨)

• ✅ 複数ブラウザサポート（Chrome, Firefox, Safari）
• ✅ 高速で安定した実行
• ✅ 豊富なアサーション機能とセレクター
• ✅ 自動待機機能（要素の表示/非表示を自動待機）
• ✅ ネットワーク監視・モック機能
• ✅ スクリーンショット・動画録画
• ✅ パフォーマンス測定機能
• ✅ アクセシビリティテスト統合

2. **Cypress** (補完的選択肢)

• 開発者フレンドリーなAPI
• リアルタイムデバッグ機能
• ※ シングルタブ制限あり

3. **WebDriver/Selenium** (レガシー対応時のみ)

• 幅広いブラウザサポート
• 成熟したエコシステム
• ※ 設定が複雑、実行速度が遅い

🧭 テスト戦略選択ガイド

UI関連タスクの場合 → **E2Eテスト最優先**

• コンポーネント作成・修正
• ページ作成・レイアウト変更
• ユーザーインタラクション実装
• フォーム機能実装
• ナビゲーション・ルーティング

ビジネスロジック・API関連タスク → **単体・統合テスト**

• データ処理アルゴリズム
• バリデーション関数
• API エンドポイント
• データベース操作
• ユーティリティ関数

テストコード作成指針

E2Eテスト重視の構造

• **Scenario-Give