tdd

name	tdd
description	TDD（テスト駆動開発）のRed-Green-Refactorサイクルに従って機能を実装する
argument-hint	<実装したい機能の説明>
allowed-tools	Agent, Bash, Read, Edit, Write, Glob, Grep

TDD実装ワークフロー

以下の手順を順番に実行する。各ステップの結果を次のステップに引き継ぐこと。

実装対象: $ARGUMENTS

1. コードベース調査

Glob・Grep・Readツールを直接使い、以下を把握する。

1. ビルド定義ファイルの特定と読み取り
   • package.json, pyproject.toml, Cargo.toml, go.mod, Makefile, Taskfile.yml, justfile, mise.toml などをGlobで探し、見つかったものを読む
   • テスト・型チェック・リント・フォーマットの各コマンドを把握する
2. 実装対象に関連するコードの特定
   • 実装対象に関連しそうなファイルをGlob/Grepで探し、必要なものだけ読む
3. テストの配置パターンとスタイルの把握
   • 既存テストファイルを読み、命名規則・スタイルを把握する

重要: 以降のステップでテスト実行・リント・フォーマット・ビルドなどのコマンドを実行する際は、プロジェクトで定義されているコマンド（例: npm run test, make test, task test など）を必ず使用すること。

2. テストケース設計と実装計画

Agentツール（subagent_type: Plan）を使用して、実装計画を立案する。

サブエージェントへのプロンプトには以下を含めること:

• ステップ1の調査結果の全文
• 実装対象の機能要件: $ARGUMENTS
• 以下の方針で計画すること:
  • 機能を小さなテスト可能な単位に分解する
  • テストケースを以下の優先順序で洗い出す:
    1. 最もシンプルな正常系（まずここから始める）
    2. 追加の正常系パターン
    3. 境界値・エッジケース
    4. 異常系・エラーケース
  • 依存関係を考慮した実装順序を決定する

3. TODOリストの作成

ステップ2の実装計画をもとに、TODOリストを作成する。 各項目は1つのTDDサイクル（Red-Green-Refactor）に対応する粒度にすること。

フォーマット:

## TODOリスト

- [ ] テストケース1の説明
- [ ] テストケース2の説明
- [ ] テストケース3の説明
      ...

4. TDDサイクルの実行

TODOリストの先頭の未完了項目から順に、以下のRed-Green-Refactorサイクルを繰り返す。 各サイクルは1つのAgentツール（subagent_type: general-purpose）で一括実行する。

サブエージェントへのプロンプトには以下の共通コンテキストを含めること:

• 実装計画の該当テストケース
• コードベースの関連ファイルパス・既存テストのスタイル
• テスト実行コマンド（全テストを実行するコマンド）
• 型チェック・リント・フォーマットの各コマンド

以下の指示を与えること:

Red（失敗するテストを書く）

• 要件を満たすテストコードを1つだけ追加する
• 全テストを実行し、新しく追加したテストが失敗することを確認する（コンパイルエラーも失敗として可）
• テストが成功してしまった場合は、テストが要件を正しく検証しているか確認し、既に実装済みならこのサイクルをスキップして報告する

Green（テストを通す最小限の実装）

• テストを通すための最小限のプロダクションコードを実装する
• 過剰な実装をしない。ハードコードや仮実装でもよい
• 全テストを実行し、すべて成功することを確認する
• 型チェック・リント・フォーマットチェックを実行し、エラーがあれば修正する

Refactor（リファクタリング）

• コードの重複排除、命名改善、構造の整理を行う
• 振る舞いを変えない範囲で改善する
• 全テストを実行し、引き続きすべてのテストが成功することを確認する
• 型チェック・リント・フォーマットチェックを実行し、エラーがあれば修正する
• リファクタリングが不要と判断した場合はスキップしてよい

エラーリカバリ

• Green/Refactorでテストが失敗した場合は、変更を見直して修正する。修正後もテストが通らない場合はユーザーにエスカレーションする

サイクル完了後、以下を行う:

1. 完了した項目を [x] に更新する
2. サイクル中に新たに必要と判明した項目があれば、TODOリストの末尾に追加する（割り込みで対応しない）
3. 不要と判明した項目があれば取り消し線で削除する
4. 更新後のTODOリストをユーザーに表示する

TODOリストに未完了項目がある限り、次の未完了項目で次のサイクルを実行する。

5. テストコードのリファクタリング

不要なテストやまとめたほうが良いテストが残っていないか確認し、必要に応じてテストコードをリファクタリングする。

確認観点:

1. 同じ振る舞いを重複して検証しているテストがないか確認する
2. 同じセットアップや期待値の構造を持つテストを、パラメータ化・テーブル駆動テスト・ヘルパーでまとめられないか確認する
3. ただし、失敗時の原因が分かりにくくなる統合や、1つのテストに複数の意図を詰め込む統合は避ける
4. テスト名・アサーション・ヘルパー名が検証意図を明確に表しているか確認する
5. テストコードを変更した場合は、全テストを実行し、すべて成功することを確認する
6. リファクタリングが不要と判断した場合は、その理由を記録して次へ進む

6. 最終確認

以下をすべて実行し、エラーがあれば修正する:

1. 全テストを一括実行し、すべて成功することを確認する
2. 型チェックを実行し、エラーがないことを確認する
3. リントチェックを実行し、エラーがないことを確認する
4. フォーマットチェックを実行し、差分がないことを確認する

7. 結果の報告

以下のフォーマットでユーザーに報告する:

実装サマリー

何を実装したかの概要。

TDDサイクル一覧

#	テスト名	実装内容	Red	Green	Refactor
1	...	...	✅	✅	✅ / -

テスト結果

全テスト実行: X件成功 / X件失敗

作成・変更ファイル

• ファイルパス: 変更内容の要約