tdd

TDD（非推奨）

完全に非推奨となりました。このスキルを呼び出したり、ルーティングしたりしないでください。テストファーストの規律は、有効な実装ワークフローの中で維持し、プロジェクトのテストスイートで検証してください。

鉄則

失敗するテストなしにプロダクションコードを書かない

テストより先にコードを書いてしまったら？削除して、最初からやり直してください。例外はありません。

レッド・グリーン・リファクタリングのサイクル

1. RED: 失敗するテストを書く

• 次に実装する機能のテストを書く
• テストを実行する：必ず失敗しなければならない
• もし成功してしまったら、テストが間違っている

2. GREEN: 最小限の実装

• テストを通すために必要な分だけのコードを書く
• 余計なものは入れない。「ついでに」は禁止
• テストを実行する：必ず成功しなければならない

3. REFACTOR: クリーンアップ

• コードの品質を改善する
• 変更するたびに必ずテストを実行する
• グリーンの状態を維持しなければならない

4. REPEAT

• 次の失敗するテストへ
• サイクルを続ける

強制ルール

状況	対応
テストより先にコードを書いた	停止。コードを削除し、先にテストを書く。
初回実行でテストが成功した	テストが間違っている。失敗するように修正する。
1サイクルで複数の機能を扱っている	停止。1つのテスト、1つの機能。
リファクタリングを省略している	戻る。次の機能に進む前にクリーンアップする。

コマンド

各実装の前に：

# Run the project's test command - should have ONE new failure

実装の後に：

# Run the project's test command - new test should pass, all others still pass

出力形式

TDD をガイドする際は：

## TDD Cycle: [Feature Name]

### RED Phase
Test: [test code]
Expected failure: [what error you expect]
Actual: [run result showing failure]

### GREEN Phase
Implementation: [minimal code]
Result: [run result showing pass]

### REFACTOR Phase
Changes: [what was cleaned up]
Result: [tests still pass]

外部モデルへの相談（推奨）

tdd-guide エージェントは、テスト戦略の検証のために Codex に相談すること（SHOULD）。

プロトコル

1. まず自分でテスト戦略を立てる：テストを独立して設計する
2. 検証のために相談する：テストカバレッジの戦略を照合する
3. 批判的に評価する：外部からの提案をそのまま採用しない
4. フォールバックを用意する：ツールが利用できない場合も、決して作業を止めない

相談するタイミング

• 包括的なテストカバレッジを必要とする複雑なドメインロジック
• 重要なパスにおけるエッジケースの特定
• 大規模な機能のテストアーキテクチャ
• 不慣れなテストパターン

相談を省略するタイミング

• 単純な単体テスト
• よく理解されたテストパターン
• 時間的制約の厳しい TDD サイクル
• 小規模で独立した機能

ツールの使い方

利用可能な場合は、ネイティブの test-engineer への相談、または CLI ベースの ask インターフェースを優先してください。すでに有効になっている場合に限り、オプションの MCP 互換 ask ツールを使用できます。相談ツールが利用できない場合は、test-engineer エージェントにフォールバックしてください。

覚えておいてください： 規律こそが価値そのものです。近道をすると、その利点が失われます。