tdd-cycle

--- name: tdd-cycle description: t-wada 流の TDD サイクルをコーディングエージェントのループに適用するための Skill。Codex またはサブエージェントが計画、テストリスト作成、E2E/受け入れテストの追加、失敗確認、最小実装、テスト通過、リファクタリング、検証記録、各工程後の別エージェントによるクロスレビューを順に行う必要があるときに使う。Linear をメモリバックエンドとする場合は、計画、テスト意図、レビュー結果、検証結果を linear-memory に記録する。 --- # TDD サイクル ## 概要 t-wada 流の TDD をループ実行の実装サイクルとして使う。基本は小さなステップで、`Red -> Green -> Refactor` を崩さない。各工程後には `$cross-review-gates` を使い、工程を担当したエージェントとは別エージェントでレビューゲートを通す。 ## 基本ルール 実装を始める前に、まずテストで期待する振る舞いを表現する。 Linear などの memory backend があり、project policy が claim を要求している場合は、controller が claim 済みであることを確認してから実装工程に入る。 標準サイクル: 1. 計画: 目的、受け入れ条件、テスト戦略、最小スコープを決める。 2. 記録: Linear が backend の場合、計画とテストリストを `$linear-memory` で記録する。 3. 設計レビュー: `$cross-review-gates` で計画とテストリストを別エージェントにレビューさせる。 4. Red: まず E2E または受け入れテストを書き、期待通りに失敗することを確認する。 5. テストレビュー: 追加したテストと Red の失敗理由を別エージェントにレビューさせる。 6. Green: 失敗しているテストを通すための最小実装を行う。 7. 実装レビュー: 実装と Green の結果を別エージェントにレビューさせる。 8. リファクタリング: テストが通った状態を保ったまま重複、命名、構造を整える。 9. リファクタリングレビュー: リファクタリング後の差分とテスト結果を別エージェントにレビューさせる。 10. 検証: E2E、関連 unit/integration、lint、type check、build など必要な検証を通す。 11. 検証レビュー: 最終検証結果と残リスクを別エージェントにレビューさせる。 12. 記録: 実装結果、レビュー結果、検証結果、残るリスクを `$linear-memory` に記録する。 ## テストリスト 作業前に小さなテストリストを作る。 ```md ## TDD 計画 目的: 受け入れ条件: ## テストリスト - [ ] E2E/受け入れ: - [ ] 境界ケース: - [ ] 回帰: ## 最初の Red テスト ## 検証コマンド ``` テストリストは完璧でなくてよい。まず一番重要な振る舞いを 1 つ選び、Red に進む。 ## E2E 優先 ユーザーに見える振る舞いやワークフローの変更では、最初に E2E または受け入れテストを書く。 - UI がある場合は、ユーザー操作と表示結果をテストする。 - API がある場合は、外部から見える request/response または契約をテストする。 - CLI がある場合は、コマンド実行と出力/exit code をテストする。 - E2E が過剰または実行不能な場合は、最も外側に近い integration/acceptance test を選び、その理由を memory に記録する。 E2E だけで細部を駆動しづらい場合は、E2E の Red を確認した後、必要な unit/integration test を追加して小さく進める。 ## レビューゲート 各工程後に `$cross-review-gates` を使う。 - 設計レビューは計画とテストリストの後に実行する。 - テストレビューは Red の確認後に実行する。 - 実装レビューは Green の確認後に実行する。 - リファクタリングレビューはリファクタリングと再テスト後に実行する。 - 検証レビューは最終検証後に実行する。 レビューは、工程を実行したエージェントとは別エージェントに担当させる。同じエージェントが自分の工程を approve してはいけない。レビュー担当が `REJECT` した場合は、同じ phase を修正して再レビューする。レビュー担当が `ESCALATE` した場合は、人間の判断を得るまで次工程へ進まない。 ## Red - 本番コードを先に大きく書かない。 - 失敗理由が期待したものか確認する。 - test harness が存在しない場合は、最小限の harness を追加し、その追加自体を小さく検証する。 - 失敗しないテストは Red ではない。テスト条件を見直す。 ## Green - 失敗しているテストを通す最小コードを書く。 - 先回りした汎用化や大きな設計変更をしない。 - 必要なら `fake it`、`obvious implementation`、`triangulation` の順に小さく進める。 - Green になったら、実行したコマンドと結果を記録する。 ## リファクタリング リファクタリングは Green の後にだけ行う。 - 外部振る舞いを変えない。 - テストを通したまま重複、名前、責務、構造を整える。 - リファクタリング後に同じ検証を再実行する。 - リファクタリングが大きくなりそうなら別 work item に分ける。 ## Linear への記録 Linear が memory backend の場合は `$linear-memory` を使う。 最初に記録するもの: - TDD 計画 - テストリスト - 最初に書く E2E/受け入れテスト - 実行予定の検証コマンド - 設計レビューの結果 最後に記録するもの: - Red の確認結果 - テストレビューの結果 - Green の確認結果 - 実装レビューの結果 - リファクタリングの有無 - リファクタリングレビューの結果 - 最終検証 - 検証レビューの結果 - 残るリスクまたはフォローアップ ## 停止条件 完了条件: - 受け入れ条件を表す E2E/受け入れテストが通っている。 - 関連する unit/integration test が通っている。 - 必要な lint/type check/build が通っている、または未実行理由が明確に記録されている。 - リファクタリング後も検証が通っている。 - 各工程後の cross-review gate が `APPROVE` になっている。 - Linear memory がある場合は、Plan と結果が記録されている。 エスカレーション条件: - 受け入れ条件をテストに落とせない。 - E2E 環境、認証、データ、外部サービスが不足している。 - テスト追加が大規模な基盤変更を要求する。 - Red の失敗理由が期待と違い、仕様判断が必要である。