TDD (Test-Driven Development) コマンド

指定したIssueファイルの内容を元に、Red-Green-Refactorサイクルを段階的にガイドし、テスト駆動開発を支援するスキルです。

このスキルは、tdd-agent サブエージェントを呼び出して、以下の7つのPhaseを自動実行します。

処理内容

Phase 1: Issue読み込みと実装仕様の抽出

• •docs/issues/ 配下のIssueファイルを検索・読み込み
• •Issueに記載された実装仕様を抽出
• •（オプション）PlanファイルへのリンクがあればPlanも読み込み
• •テスト対象ファイルとテストファイルのパスを特定

Phase 2: 赤フェーズ（Red）- 失敗するテストを作成

• •まだ実装されていない機能に対するテストを作成
• •TDD原則に従ったテストコード生成:
  • •テストデータはテスト関数内に記述
  • •モックは外部依存のみ
  • •WHYコメントを重視

Phase 3: テスト実行（Red確認）

• •unit-test-runner エージェントでテストを実行
• •テストが期待通り失敗することを確認

Phase 4: 緑フェーズ（Green）- 最小限の実装

• •テストを通す最小限のコードを実装
• •過剰な実装や最適化は避ける

Phase 5: テスト実行（Green確認）

• •unit-test-runner エージェントでテストを実行
• •テストが成功することを確認

Phase 6: リファクタリング（Refactor）

• •テストが通った状態でコードを整理・改善
• •重複排除、変数名改善、可読性向上
• •動作を変えないことを保証

Phase 7: 最終確認（Final Verification）

• •unit-test-runner エージェントでテストを実行
• •リファクタリング後も全テストが成功することを確認
• •TDDサイクル完了レポートを表示

使用方法

基本的な実行

/tdd [Issue番号またはファイル名]

引数あり:

/tdd 15                      # Issue番号で指定
/tdd 15-state-validation.md  # ファイル名で指定

引数なし:

/tdd                         # 対話的にIssue番号を入力

前提条件

1. •

   Issueファイルが存在すること

   • •/create-issue で事前に作成
   • •docs/issues/ 配下に配置
2. •

   設計書が更新済みであること（推奨）

   • •/update-design で設計書を更新済み
   • •実装が設計書に沿っていることを確認
3. •

   Issueに必要な情報が記載されていること

   • •ラベル（backend/frontend）
   • •対象ファイル
   • •実装する機能の説明

TDD原則の強制

エージェントは以下のTDD原則をチェックし、違反があれば警告を表示します:

• •小さな単位でテストを作成: 1つのテストケースは1つの動作のみ検証
• •テストデータはテスト関数内に記述: fixtureは最小限（assertionに無関係なデータのみ）
• •モックは外部依存のみ: 過度なモックは設計見直しを提案
• •WHYコメントを重視: なぜこのテスト・実装が必要かを明記
• •最小限の実装: テストを通すために必要な最小限のコードのみ（Green Phase）
• •動作を変えない: リファクタリングではテストが通ることが前提

既存コマンドとの関係

開発フロー全体における位置付け

1. アイデア作成（docs/idea）
   ↓
2. Plan作成（docs/plan）
   ↓
3. Issue作成（/create-issue）
   docs/issues/15-state-validation.md 作成
   ↓
4. 設計書更新（/update-design）
   docs/design/backend-design.md 更新
   ↓
5. 設計書レビュー（人間 + /doc-reviewer）
   ↓
6. 実装（/tdd）← 本コマンド
   backend/src/utils/state.ts 実装
   backend/src/utils/state.test.ts 作成
   ↓
7. 静的解析・全テスト（/ci）
   プロジェクト全体の品質チェック
   ↓
8. コードレビュー（/review）
   ↓
9. 設計書整合性チェック（/validate-design）

/tddの役割

従来のフロー:

Issue → 設計書 → 手動でテスト作成 → 手動で実装 → テスト実行

新しいフロー:

Issue → 設計書 → /tdd（自動でTDDサイクル） → 完成

他コマンドとの違い

• •

  テスト実行スコープ:

  • •/tdd: 対象ファイルのテストのみ実行（高速フィードバック）
  • •/ci: プロジェクト全体のテスト実行（網羅的チェック）
• •

  静的解析:

  • •/tdd: 静的解析は含まない（実装に集中）
  • •/ci: ESLint, Prettier等の静的解析を実行

使用技術

詳細なエージェント仕様

TDDサイクルの詳細ロジック、7つのPhaseの処理フロー、TDD原則チェックの詳細は、.claude/agents/tdd-agent/ で定義されています。

実行指示（Claude Code への指示）

このスキルが呼び出されたら、以下を厳格に実行すること:

1. エージェントの起動

Task ツールを使用して tdd-agent サブエージェントを起動:

subagent_type: "tdd-agent"
prompt: "指定されたIssueファイルからTDDサイクル（Red-Green-Refactor）を実行してください"

2. 出力の表示

エージェントが完了したら、その出力をそのまま全文表示すること。

重要: 以下の行為は禁止:

• •エージェントの出力を要約する
• •エージェントの出力を加工する
• •エージェントの出力にコメントを追加する

許可される行為:

• •エージェントの出力を全文そのまま表示する

エージェントの出力には、TDDサイクルの各Phase結果、完了レポート、Next Actionが含まれているため、ユーザーにそのまま提示すること。