tdd-cyclelisted

# TDD サイクル管理スキル J-SIX プロセスの Phase 4（TDD 実装）で、Red→Green→Refactor サイクルを管理する。 ## 前提条件 - Phase 3 で承認されたタスク定義（受入条件付き）が存在すること - CLAUDE.md が整備済みであること ## TDD サイクル手順 ### Step 1: タスク確認 ユーザーからタスク定義を受け取り、以下を確認: - タスクID と名称 - 受入条件（検証可能な形式であること） - 依存関係 - CLAUDE.md のコーディング規約・テスト方針 ### Step 2: Red Phase（テスト作成） 1. 受入条件からテストケースを設計する 2. テストコードを作成する - 正常系テスト - 異常系テスト（バリデーション、エラーハンドリング） - 境界値テスト 3. テストを実行し、**全て失敗する**ことを確認する 4. コミットする（メッセージ: `test: [タスクID] Red - [テスト内容の要約]`） ### Step 3: Green Phase（最小実装） 1. テストが通る**最小限の**実装を書く 2. テストを実行し、**全て成功する**ことを確認する 3. コミットする（メッセージ: `feat: [タスクID] Green - [実装内容の要約]`） ### Step 4: Refactor Phase（リファクタリング） 1. コードの品質を改善する（命名、構造、重複排除） 2. テストが**引き続き全て成功する**ことを確認する 3. 必要に応じてコミットする（メッセージ: `refactor: [タスクID] [改善内容]`） ### Step 5: ADR 記録（該当する場合） 実装中に以下の判断が発生した場合、ADR を記録する: - ライブラリ・フレームワークの選択 - データ構造やアルゴリズムの選択（非自明な場合） - パフォーマンスとのトレードオフ - セキュリティに関わる判断 ADR テンプレート: `templates/adr/template.md` を使用 ## エスカレーション条件 以下の場合はユーザーに判断を仰ぐ: - 受入条件に曖昧さがある - 設計判断が必要（Spec に記載のない技術的判断） - テストが3回連続で失敗する - セキュリティに関わる判断が必要 - 外部インターフェースの変更が必要 - アーキテクチャの変更が必要（CLAUDE.md で変更禁止のファイル等） ## 完了条件 - [ ] 全受入条件に対応するテストが存在する - [ ] 全テストが成功している - [ ] コードが CLAUDE.md の規約に準拠している - [ ] 必要な ADR が記録されている - [ ] コミット履歴が Red→Green→Refactor の流れを反映している