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を通す最小実装」一言）