tdd-planning

TDD 計画

厳格なテスト駆動開発のアプローチに従った実装計画を作成します。実装の各ステップでは、TDD サイクルである RED → GREEN → COMMIT/ROLLBACK に従います。

TDD の基本原則

このスキルでは、規律ある TDD ワークフローを徹底します。

1. RED：まず失敗するテストを作成します（正しい理由で失敗する必要があります）
2. GREEN：テストをパスさせる最小限のコードを記述します（それ以上は不要です）
3. COMMIT/ROLLBACK：テストがパスしたらコミットします。行き詰まった場合は、最後にパスした状態までロールバックします。

失敗するテストを先に作成せずに、実装コードを書くことはありません。 これは絶対に守る必要があります。

作業上の取り決め

これらの指示は、あなたとユーザーの間の作業上の取り決めを定めます。主な原則は次のとおりです。

1. AskUserQuestion は主要なコミュニケーション手段です - 確認事項（詳細の確認、設計上の決定、希望、承認など）をユーザーに尋ねる必要がある場合は、必ず AskUserQuestion ツールを使用します。質問を通常のテキストで出力せず、ユーザーが効率よく回答できるよう、常に構造化されたツールを使ってください。

2. 最初に希望を確認します - ユーザーが先に進みたいと思う可能性がある最後ではなく、ワークフローの開始時にユーザーの希望を尋ねます。

3. 自律性モードに応じて対話の頻度を決めます - ユーザーが選択した自律性レベルによって確認の頻度は変わりますが、質問には常に AskUserQuestion を使用します。

ユーザーの希望

計画を始める前に（自律性モードが Autopilot の場合を除く）、以下の希望を確認します。

コミットの粒度 - 次の質問を AskUserQuestion で尋ねます。

質問	選択肢
"コミットの粒度はどの程度にしますか？"	1. GREEN のたびにコミット（厳格な TDD に推奨）、2. 機能／フェーズの完了ごとにコミット、3. コミットは自分で行う

ロールバック戦略 - 次の質問を AskUserQuestion で尋ねます。

質問	選択肢
"妥当な範囲で試してもテストをパスさせられない場合、どのロールバック戦略を取りますか？"	1. 最後のコミットまで git checkout . を実行（推奨）、2. 後で分析できるよう変更を git stash する、3. 失敗するコードを残して、対応方法を尋ねる

ファイルレビューの設定 - file-review:file-review が利用可能なコマンドに含まれているかを確認して、file-review プラグインが利用可能か調べます。

file-review プラグインがインストールされている場合は、次の質問を AskUserQuestion で尋ねます。

質問	選択肢
"計画の準備ができたときに、インラインフィードバック用に file-review を使いますか？"	1. はい。計画の準備ができたら file-review を開く（推奨）、2. いいえ。計画を表示するだけにする

これらの希望を記録し、実装時に反映します。

使用する場面

このスキルは、次の場合に有効になります。

• ユーザーが TDD 計画コマンドを実行したとき
• 別のスキルが **REQUIRED SUB-SKILL:** Use desplega:tdd-planning を参照しているとき
• ユーザーが TDD に基づく計画を明示的に依頼したとき
• 実装する機能がテスト上または安全上、重大な影響を伴うとき

自律性モード

計画の開始時に、自律性モードに応じて対話の頻度を調整します。

モード	動作
Autopilot	独自に調査し、TDD の完全な計画を作成して、最終確認のためだけに提示します
Critical（デフォルト）	主要な決定ポイントで合意を得て、テスト戦略を検証します
Verbose	各ステップで確認を取り、サイクルごとにテストの進め方を確認します

自律性モードは、呼び出し元のコマンドから渡されます。指定がない場合は、Critical をデフォルトとします。

プロセスの手順

ステップ 1：コンテキストの収集とテストインフラストラクチャの分析

1. 言及されているファイルをすべて、すぐに最後まで読みます：

   • 調査ドキュメント、関連する計画、JSON／データファイル
   • 重要：Read ツールは limit／offset パラメーターを指定せずに使用してください
   • 必須：サブタスクを開始する前に、自分でファイルを読んでください

2. テストインフラストラクチャを分析します：

   • どのテストフレームワークを使用していますか？（Jest、pytest、Go testing など）
   • テストはどこにありますか？（ソースと同じ場所、__tests__/、tests/ など）
   • テストコマンドは何ですか？（npm test、make test、pytest など）
   • 参考にできる既存のテストパターンはありますか？

3. 初期調査タスクを開始します：

   • codebase-locator エージェントを使って、テストファイルとテストユーティリティを探します
   • codebase-analyzer エージェントを使って、現在のテストパターンを把握します
   • codebase-pattern-finder エージェントを使って、類似するテスト実装を探します
   • テストライブラリに関する情報を得るため、context7 MCP を使います

4. 理解した内容と質問を提示します（Autopilot でない場合）：

   まず、調査結果をテキストで提示します：

   Based on the research of the codebase, I understand we need to [summary].
   
   Test Infrastructure:
   - Framework: [testing framework]
   - Test location: [where tests live]
   - Test command: `[command]`
   - Existing patterns: [relevant patterns found]
   

   次に、質問がある場合は AskUserQuestion を使います。

ステップ 2：テスト戦略の設計

1. テスト可能な単位を特定します：

   • 最小のテスト可能な要素は何ですか？
   • どの入力／出力を検証できますか？
   • 重要なエッジケースは何ですか？

2. テストの進め方を設計します：

   • 最も単純なケース（正常系）から始めます
   • エッジケースへと進めます
   • エラー処理で締めくくります

3. テスト戦略を提示します（Autopilot でない場合）：

   AskUserQuestion を使って、アプローチの確認を求めます：

   質問	選択肢
   「[最も単純なテストケース] から始め、[より複雑なケース] へ進むことを提案します。このテストの進め方でよいですか？」	1. はい、進めてください、2. 順序について相談する、3. テストケースを追加する

ステップ 3：計画の構成を作成する

1. TDD サイクルの概要を作成します：

   各機能／フェーズを TDD サイクルに分割します：

   ## Feature: [Name]
   
   ### Cycle 1: [Simplest behavior]
   - RED: Test for [specific behavior]
   - GREEN: Implement [minimal code]
   - COMMIT: "[descriptive message]"
   
   ### Cycle 2: [Next behavior]
   ...
   

2. 詳細を書く前に、構成についてフィードバックを得ます（Autopilot の場合を除く）

ステップ 4：詳細な計画を作成する

続行する前に、計画モードを終了して計画ファイルを作成します。

計画は thoughts/<username|shared>/plans/YYYY-MM-DD-tdd-description.md に書き込みます。

パスの選択： コンテキストからユーザー名がわかる場合は、ユーザー名を使用します（例：thoughts/taras/plans/）。判断できない場合は、thoughts/shared/plans/ を使用します。

必須：すべての TDD サイクルに、記述するテストコードと想定される失敗メッセージを正確に含めてください。正確な形式についてはテンプレートを参照してください。

QA 仕様（任意）： ユーザー向けの動作を変更する機能には、機能レベルで任意の ### QA Spec (optional): セクションを含めることを推奨します（機能ヘッダーの後、最初の TDD サイクルの前）。QA 仕様をフェーズごとに記載する通常の計画とは異なり、TDD 計画では機能ごとに記載します。RED／GREEN サイクル自体が各サイクルの検証となるためです。形式についてはテンプレートを参照してください。

テンプレート： cc-plugin/base/skills/tdd-planning/template.md にあるテンプレートを読み、その指示に従ってください。

ステップ 5：レビューと反復

1. ドラフトプランの場所を提示する：

   I've created the TDD implementation plan at:
   `thoughts/<username|shared>/plans/YYYY-MM-DD-tdd-description.md`
   
   Please review it.
   

2. フィードバックに基づいて反復する（Autopilot でない場合）

3. 構造化されたレビューを提案する：

   • 反復後、「この TDD プランの完全性とギャップを分析するために、/review を実行しますか？」と尋ねます。
   • はいの場合、プランのドキュメントに対して desplega:reviewing スキルを実行します

4. 学びの記録：

   任意のサブスキル： このワークフローで重要な知見、パターン、注意点、または決定事項が生じた場合は、desplega:learning を使用して /learning capture で記録することを検討してください。今後のセッションでほかの人に役立つ学びに焦点を当てます。

5. ワークフローの引き継ぎ： プランが確定した後（レビューは任意）、AskUserQuestion を使用して次のように尋ねます：

   質問	選択肢
   "TDD プランの準備ができました。次のステップは何ですか？"	1. このプランを実装する（→ /implement-plan）、2. 先にレビューを実行する（→ /review）、3. 今回はここまでにする（プランを保留する）

   回答に基づいて：

   • 実装：プランのファイルパスとともに /implement-plan コマンドを提案します
   • レビュー：プランのドキュメントに対して desplega:reviewing スキルを実行します
   • 完了：必要に応じて、プランの status を ready または parked に設定します

6. プランを確定する - 実装を開始しないでください

レビューとの連携

file-review プラグインが利用可能で、ユーザーがユーザー設定のセットアップ時に「はい」を選択した場合：

• プランの作成後、/file-review:file-review <path> を実行します
• ユーザーが「いいえ」を選択した場合、または自律性モードが Autopilot の場合は、このステップをスキップします

TDD サイクルの要件（必須）

すべての実装ステップで、必ず TDD サイクルに従ってください。 適切な TDD サイクルのないプランは不完全です。

各サイクルで必要な構成

### Cycle N: [Behavior being implemented]

#### RED Phase
**Test to write:**
```[language]
// Exact test code goes here

想定される失敗：

[Expected error message or failure output]

RED を検証： [test command] は上記のメッセージで失敗するはずです

GREEN フェーズ

実装方針： [必要最小限のコードの簡単な説明]

変更するファイル：

• path/to/file.ext: [追加または変更する内容]

GREEN を検証： [test command] は成功するはずです

COMMIT/ROLLBACK

GREEN の場合：

• コミットメッセージ："[descriptive message following conventional commits]"
• コマンド：git add -A && git commit -m "[message]"

行き詰まった場合（妥当な努力をしても GREEN に到達できない場合）：

• ロールバック：git checkout .（または好みに応じて git stash）
• 再評価：テストの範囲が広すぎないか、または設計を再考する必要がないか検討します

### Validation Checklist

Before finalizing any TDD plan, verify:
- [ ] Every implementation step has RED → GREEN → COMMIT/ROLLBACK structure
- [ ] RED phase includes exact test code to write
- [ ] RED phase includes expected failure message
- [ ] GREEN phase describes minimal implementation
- [ ] Each cycle is small enough to complete in one sitting
- [ ] Cycles build on each other progressively
- [ ] Rollback strategy is clear for each cycle

## Important Guidelines

1. **Tests First, Always**: Never describe implementation without the test that drives it
2. **Minimal GREEN**: Only write enough code to pass the test, nothing more
3. **Small Cycles**: If a cycle seems big, break it into smaller cycles
4. **Progressive Complexity**: Start simple, add complexity through new tests
5. **Clear Rollback Points**: Every commit is a safe point to return to
6. **No Speculative Code**: Don't add code "because we'll need it later"