TDD（test-first / RED を必ず観測）

テストの書ける領域での機能開発における test-first の既定手順。

大原則: テストの失敗を見ていないなら、正しいものをテストしている確証は無い

実装を書く前に、まず失敗するテストを書き、その失敗（RED）を実際に観測する。 「通ると思ったテストが最初から通ってしまった」場合、そのテストは対象を検証していない （誤った前提・誤ったアサーション・実装済みの何かを叩いているだけ）。RED を見て初めて、 そのテストが意味を持つ。

サイクル: RED → GREEN → REFACTOR

1. RED: これから作る振る舞いに対する失敗するテストを 1 つ書く。実行して失敗を観測する。 失敗メッセージが「期待した理由で」失敗しているかまで確認する（未定義エラーで落ちただけ、を避ける）。
2. GREEN: そのテストを通す最小限の実装を書く。ここで余計な機能を足さない（YAGNI）。 テストを実行し、**通る（GREEN）**ことを確認する。
3. REFACTOR: GREEN を保ったまま整理する。リファクタの前後でテストが通り続けることを確認する。

1 サイクル 1 振る舞い。複数の振る舞いを 1 サイクルに詰め込まない。

最小例（一例: PHP + Pest。他言語・他ランナは読み替える）

// tests/Feature/InvoiceTotalTest.php
it('合計に消費税を加算する', function () {
    $invoice = Invoice::factory()->create(['subtotal' => 1000]);

    expect($invoice->total())->toBe(1100); // 消費税 10%: 1000 * 1.1 = 1100（int 返却想定）。未実装なので RED
});

テストランナで先に失敗を観測してから、total() を実装して GREEN にする （実行コマンドは各プロジェクト・各フレームワークの方式に従う）。 単体/機能テストは本 skill 内で完結する。実装後の画面影響・回帰確認は affected-area-testing skill やブラウザ自動化（Playwright 等）で行う。

適用範囲（強制しない場所）

• 機能開発の既定手順として借用する。絶対法ではない。
• superpowers の「テスト前に書いた本番コードは全て削除する」絶対ルールは採らない。 「シンプル第一」「字面でなく意図で動く」と衝突しうるため。既に妥当な実装がある／ 探索的に書いたコードが正しいなら、テストを後追いで固める判断もしてよい（意図で動く）。 ただし後追いで固める場合も、実装を一時的に壊す等して失敗（RED 相当）を一度は観測し、 そのテストが対象を本当に検証していることを担保する（大原則は死守する）。
• 設定・インフラ・ビルド/CI・自明な変更・テストの書きづらい UI 微調整には強制しない。
• テストランナの無い領域（設定・shell スクリプト等）は対象外。そこでは「失敗を先に固定してから直す」 バグ調査の規律（systematic-debugging skill）で代替する。

関連 skill との棲み分け

• tdd（本 skill）= 開発前の test-first（これから作る振る舞いを RED から始める）。
• バグ調査での RED 観測（既存の不具合を再現する失敗を先に固定）= systematic-debugging skill。
• 改修後の段階テスト（基本→新機能→統合→回帰、ブラウザ自動化中心）= affected-area-testing skill。単体テストは本 skill 側で回す。