| name | tdd-red |
| description | TDDのレッド(RED)フェーズを厳密に実行する。Spec/受入条件から「1つ」選び、失敗するテストを「1本だけ」追加して実行し、失敗(RED)を確認する。仕様が不明瞭なら実装に進まず、質問/Spec更新提案を行う。 |
tdd-red（レッド：失敗するテストを書く）
このスキルの目的
- これから達成する振る舞いを「テストとして1つに絞って」明確化する（実行可能な例）。
- 失敗理由が一目で分かる粒度で、必ずREDを作る。
前提（満たさない場合は停止）
- 対象Spec（例：
docs/specs/YYYYMMDD-*.md）が存在し、少なくとも- 具体的なハッピーケース 1つ
- 代表的な失敗ケース 1つ が言語化されている。
- Specが曖昧／未決（Open Questions）が「今回のテスト設計に直結」する場合は、勝手に解釈せずユーザーに質問し、Spec更新案を提示して止まる。
入力として扱う情報（会話・リポジトリから収集）
- 対象Specのパス（不明なら検索して提示）
- 対象モジュール/機能の範囲
- 既存テストの実行方法（例：
cargo testなど）
手順（厳守）
- フェーズ宣言（あなたの返答冒頭に必ず出す）
Current Phase: RED
- テストTODOリストを作る（または更新する）
- Specの受入条件（またはTODO）を箇条書き化し、今回やる項目を 1つだけ選ぶ。
- 選んだ項目に
Spec-ID（例：AC-001）を割り当て、以後テスト名/コメントに埋め込む。
- 失敗するテストを1本だけ追加する
- 1テスト=1振る舞い。複数の期待を詰め込まない。
- テストは「実装の内部構造」ではなく「観測可能な振る舞い」を表現する（可能な限り）。
- 依存が重い場合は、まずは境界を薄く切って最小の単位テストに落とす（ただし過剰なモック地獄は避ける）。
- テストを実行してREDを確認する
- 新テストが確実に失敗していること、失敗理由が期待どおりであることを確認する。
- 既存テストの状況も確認し、今回の失敗が「新テスト由来」であることを切り分ける。
ガードレール（やってはいけない）
- テストを複数本まとめて追加しない（AIに“先に全部書かせる”をしない）。
- 実装コードを先に触らない（REDではテストのみ）。
- Specに書かれていない振る舞いを、テストに“善意で”足さない。
- 失敗が曖昧なテスト（環境依存・タイミング依存・失敗理由が不明）を作らない。
出力フォーマット（返答はこれに従う）
Current Phase: RED対象Spec:（パス）今回の対象(1つ):（Spec-ID + 受入条件の要約）追加したテスト:（ファイルパス + テスト名）実行コマンド:（実際に走らせたコマンド）結果:（REDであることの要約。ログは必要最小限）次:tdd-greenに進むための前提（「このREDを通す最小実装」一言）