/tdd-green

description: TDDのGreenフェーズを実行します。失敗しているテストケースを通すための実装を行い、テストが成功することを確認します。
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite
argument-hint: "[要件名] [TASK-ID]"

TDDのGreenフェーズを実行し、Redフェーズで作成したテストを通すための実装を行います。

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

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

step3: 実装の実行

• **仕様との差異確認**:
• 実装前に要件定義ファイルとテストケースファイルの内容を精査
• 現在の実装コードと仕様の間に差異を発見した場合：

1. 差異の内容を具体的に特定 2. どちらが正しいか判断できない場合は AskUserQuestion ツールを使用してユーザに確認 3. 「仕様: [仕様の記述]」「実装: [実装の内容]」を明示して質問 4. ユーザの判断を待ってから実装を進める

• <implementation_template> の方針に従って実装を行う
• 読み込んだコンテキスト情報を活用
• 信頼性レベル（🔵🟡🔴）を各実装に記載
• 必須の日本語コメントを含める
• ファイルサイズを意識（800行制限）
• モック使用の制限を遵守

• テストを実行し、結果を確認する
• **選択的実行**: 実装したファイルに関連するテストのみを実行（高速）
• Jest: `npm test -- --findRelatedTests <実装ファイル>`
• pytest: `pytest <関連テストファイル>`
• 特定のテストスイート: `npm test -- <テストパターン>`
• 全てのテストが通ることを確認
• 失敗した場合は原因を調査し、修正を繰り返す
• 既存のテストがエラーになった場合は仕様を元に適切に修正
• **注意**: 全体のテスト実行は verify-complete フェーズで実施

• 実装内容について、品質判定基準に基づいて以下を評価：
• テスト成功状況
• 実装のシンプルさ
• リファクタリング箇所の明確性
• 機能的問題の有無
• ファイルサイズ（800行制限）
• モック使用の適切性

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

step4: ドキュメント更新

• **Green-phaseファイルの作成・更新**：
• 実装コードと設計内容を {{Greenフェーズファイル}} に保存
• 既存ファイルがある場合は追記
• 以下の内容を記録：
• 実装したコードの全文
• 実装方針と判断理由
• テスト実行結果
• 課題・改善点（Refactorフェーズで対応）

• **メモファイルの更新**：
• {{メモファイル}} のGreenフェーズセクションを更新
• 既存のメモファイルがない場合は新規作成（TDDメモファイル形式に従う）
• 以下の内容を記録：
• 実装日時
• 実装方針
• 実装コード
• テスト結果
• 課題・改善点

• step5 を実行する

step5: TODO更新と次ステップ判定

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

• **自動遷移判定**: 以下の条件を満たす場合は自動で `/tsumiki-legacy:tdd-refactor {要件名} {TASK-ID}` を実行
• Taskツールを使用して全てのテストが成功していることを確認済み
• 実装がシンプルで理解しやすい
• 明らかなリファクタリング箇所がある
• 機能的な問題がない

• **手動確認**: 自動遷移条件を満たさない場合は以下を提供：
• 「Taskツールを使用してテストが通ったことを確認しました。」
• 「現在の実装: [簡潔な説明]」
• 「実装に含めた日本語コメント: [コメントの目的と内容]」
• 「リファクタリングの候補: [改善すべき点]」
• 「次のRefactorフェーズに進んでよろしいですか？」

rules

実装の原則

• **仕様との整合性確認が最優先**
• 実装前に必ず仕様（要件定義・テストケース）と現在の実装を照合する
• 差異を発見した場合は独断で進めず、AskUserQuestion ツールでユーザに確認を求める
• **テストが確実に通ること最優先**
• コードの美しさは二の次（次のRefactorフェーズで改善）
• 「とりあえず動く」レベルでOK
• 複雑なロジックは後回し、シンプルな実装を心がける
• テストがなかなか通らないときは、Taskツールを使用して失敗原因を調べてから修正の計画を立てて実装する
• 既存のテストがエラーになった場合は仕様を元に適切に修正する

禁止事項（NEVER）

• 必要なテストのスキップ禁止
• 必要なテストの削除禁止
• 実装コード内でのモック・スタブの記述禁止
• 実装コード内でDBに代わるインメモリーストレージの利用禁止
• 実装コード内でDB操作の省略禁止

ファイルサイズ管理

• **800行制限**: 実装ファイルが800行を超えた時点でファイル分割を検討
• **モジュール設計**: 機能単位でファイルを適切に分離
• **関数分割**: 長大な関数は小さな単位に分割して実装
• **責任境界**: 各ファイルの責任範囲を明確にして実装
• **分割戦略**: 機能・レイヤー・ドメインでファイルを分離

モック使用の制限

• **実装コード制限**: 実装コード内でモック・スタブを使用しない
• **テストコード限定**: モックはテストコード内でのみ使用
• **実際のロジック実装**: 実装コードは実際の処理を記述する
• **依存関係注入**: 必要に応じて依存性注入パターンで実装

段階的実装のガイドライン

1. **まず1つのテストケースだけ通す**

• 複数テストの同時対応は複雑化を招くため避ける
• 1つずつ確実に実装することで品質を担保

2. **最も簡単な方法で実装**

• 複雑なアルゴリズムは後のリファクタで追加
• 可読性重視：現段階では理解しやすさを最優先

3. **コード品質基準の考慮**

• 静的解析対応：lintやtypecheckでエラーが出ない実装を心がける
• フォーマット統一：プロジェクトの既存フォーマットに合わせた実装
• 命名規則遵守：プロジェクトの命名規則に従った実装

4. **他のテストケースは後回し**

• TDDの原則に従い、1ステップずつ進める
• 変更の影響を最小限に抑える

5. **エラーハンドリングも最小限**

• テストで要求される部分のみ実装
• リファクタ段階で詳細なエラー処理を追加予定

信頼性レベル指示

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

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

品質判定基準

✅ 高品質:
- テスト結果: Taskツールによる実行で全て成功
- 実装品質: シンプルかつ動作する
- リファクタ箇所: 明確に特定可能
- 機能的問題: なし
- コンパイルエラー: なし
- ファイルサイズ: 800行以下または分割計画が明確
- モック使用: 実装コードにモック・スタブが含まれていない

⚠️ 要改善:
- テストの一部が失敗（Taskツールで検出）
- 実装が複雑すぎる
- リファクタ方針が不明
- 機能に懸念がある
- コンパイルエラーが存在
- ファイルサイズが800行を超過し分割計画が不明
- 実装コードにモック・スタブが含まれている

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

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

info

<implementation_template>

実装時の日本語コメント要件

実装コードには以下の日本語コメントを必ず含めてください：

関数・メソッドレベルのコメント

/**
 * 【機能概要】: [この関数が何をするかを日本語で説明]
 * 【実装方針】: [なぜこのような実装方法を選んだかを説明]
 * 【テスト対応】: [どのテストケースを通すための実装かを明記]
 * 🔵🟡🔴 信頼性レベル: [この実装が元資料のどの程度に基づいているか]
 * @param {type} paramName - [パラメータの説明]
 * @returns {type} - [戻り値の説明]
 */
function {{function_name}}(paramName) {
  // 【実装内容】: [実装している処理の詳細説明]
}

処理ブロックレベルのコメント

function processData(input) {
  // 【入力値検証】: [入力値の妥当性をチェックする理由と方法] 🔵🟡🔴
  if (!input) {
    throw new Error('入力値が不正です'); // 【エラー処理】: [なぜこのエラーが必要かを説明] 🔵🟡🔴
  }

  // 【データ処理開始】: [メイン処理の開始を明示] 🔵🟡🔴
  // 【処理方針】: [この処理がテストを通すためにどう貢献するかを説明] 🔵🟡🔴
  const result = {
    // 【結果構造】: [戻り値の構造とその理由を説明]
    validData: [],
    invalidData: [],
    errors: [],
  }