| name | tdd-green |
| description | TDDのグリーン(GREEN)フェーズを厳密に実行する。REDの「1本だけ」失敗しているテストを通すために、最小限のプロダクションコードだけを実装し、全テストGREENを確認する。余計な機能追加・設計改善はしない。 |
tdd-green（グリーン：テストをパスさせる）
このスキルの目的
- REDで示された要件を、最小限の実装で満たしてGREENにする。
- “動作する”を最優先し、設計の美しさは次（Refactor）に先送りする。
前提（満たさない場合は停止）
- 直前のREDで追加した「失敗テストが1本」に特定できている。
- その失敗が仕様（Spec-ID）と一致している。
- Specが曖昧で実装判断が必要なら、ここで止めて質問／Spec更新提案に戻す。
手順（厳守）
- フェーズ宣言
Current Phase: GREEN
- ターゲットを固定
- “通すべきテストはどれか”を明示する（Spec-ID/テスト名）。
- 最小実装で通す
- まずは最短距離でGREENを作る（必要なら仮実装も可）。
- Specやテストで明示されていない振る舞いを追加しない（YAGNI）。
- インターフェースの拡張・抽象化・共通化は原則禁止（Refactorでやる）。
- 全テスト実行でGREEN確認
- 新テストだけでなく、既存テストも含めてGREENを確認する（回帰を許さない）。
- 気づきをTODOへ戻す
- “いまは汚いが動いた”点を、次のRefactorのTODOに1〜3点で記録する（やりすぎ防止）。
ガードレール（やってはいけない）
- GREEN中にリファクタリングを始めない（関数分割・命名改善・抽象化などは原則Refactor）。
- Spec外の機能を増やさない（「ついで」禁止）。
- テストを増やして三角測量に入るのは、次のREDとして扱う（GREENでやらない）。
出力フォーマット（返答はこれに従う）
Current Phase: GREEN対象Spec-ID / テスト:（1つ）最小実装の方針:（1〜2行）変更点:（主なファイルパスの列挙）実行コマンド:（実際に走らせたコマンド）結果:（全テストGREENの要約）次:tdd-refactorのTODO（最大3つ）