tdd-test-writer

TDD テスト作成者

このスキルを使用して、TDD の RED フェーズを完了します。まずテストで振る舞いを定義し、正しい理由で失敗することを確認してから、客観的な合格基準とともに実装を引き継ぎます。

使用するタイミング

ユーザーから次の依頼があった場合に、このスキルを使用します。

• テストファースト開発
• TDD の RED-GREEN-REFACTOR ワークフロー
• 実装エージェントが満たす必要のあるテストの作成
• コードを変更する前に回帰テストが必要なバグ修正

必須ルール

1. このスキルの実行中は、本番コードを変更しないでください。
2. RED フェーズのテスト作成には、利用可能な場合、サブエージェントのロール tdd_test_writer を使用してください。
3. プレースホルダーではなく、振る舞いに焦点を当てたテストを作成してください。
4. 新規作成または更新するすべてのテストは、引き継ぎ前に失敗する必要があります。
5. 失敗の原因は、本番環境の振る舞いが不足しているか誤っていることでなければなりません。テストの不備が原因であってはなりません。
6. 可能な限り、フルスイートの実行より、決定的で対象を絞ったテストコマンドを優先してください。
7. バグ修正タスクでは、報告された失敗モードを再現する回帰テストを追加してください。

ワークフロー

1. 振る舞いの契約を定義する

• ユーザーの依頼を、明示的な受け入れ基準に変換します。
• 正常系、エッジケース、異常系で期待される振る舞いを特定します。
• 要件が曖昧な場合は、出力に ASSUMPTION: 行を記録します。

2. テスト作成を tdd_test_writer に委任する

• タスクの範囲、対象ファイル、受け入れ基準を指定して、tdd_test_writer サブエージェントを起動します。
• サブエージェントには、テストのみを作成・更新し、本番コードは変更しないよう求めます。
• 新しいテストが RED 状態で失敗したことを示すコマンド出力を求めます。
• tdd_test_writer を利用できない場合は、直接作業を続け、FALLBACK: tdd_test_writer unavailable と記録します。

3. 既存のテスト規約を確認する

• リポジトリからフレームワークとランナーを特定します（例：vitest、jest、pytest、go test、cargo test）。
• 既存のディレクトリ、命名、フィクスチャの規約に従います。
• 重複するテストユーティリティを導入するのではなく、既存のヘルパーを再利用します。

4. RED フェーズのテストを作成する

• 振る舞いの契約を表すテストファイルを作成または更新します。
• テストは小さく、意図が明確になるようにします（分かりやすい名前とアサーションを使用します）。
• 該当する場合は、異常系のアサーションを少なくとも 1 つ含めます。
• ネットワークや時間によるランダム性を避け、外部システムをモックするかフィクスチャを使用します。

5. RED 状態を確認する

• 新しいテストを実行する、最も対象を絞ったコマンドを実行します。
• 期待される振る舞いの不足が原因で失敗していることを確認します。
• テストの構文やセットアップが原因で失敗した場合は、テストを修正して再実行します。

6. 実装引き継ぎを作成する

実装エージェントが従うべきブロックを返します。引き継ぎには次の内容を含めます。

• 使用したサブエージェント（tdd_test_writer）、または明示的なフォールバック理由
• 作成・更新した正確なテストファイル
• 正確な検証コマンド
• RED 状態を証明する簡潔な失敗の概要
• テストを変更しないという制約（要件が変更された場合を除く）
• タスクの完了を定義する合格基準

必須の出力形式

TDD RED PHASE COMPLETE

## Authoring Mode
- Subagent: tdd_test_writer
- Fallback: [only if subagent unavailable]

## Test Files
- [path]

## Verification
- Command: [exact command]
- Result: FAIL (expected)
- Failure reason: [1-2 lines tied to missing behavior]

## Implementation Contract (for next agent)
1. Do not modify these tests: [paths]
2. Implement production changes only in: [paths or modules]
3. Completion gate: [exact command] passes with no test weakening.
4. Run broader safety check: [secondary command]
5. Return evidence: changed files + command output summary.

## Assumptions
- ASSUMPTION: [only if needed]

品質基準

• 実装前にテストが失敗し、ローカル環境で再現できます。
• 誤検出を防げるだけの具体性を持つアサーションが記述されています。
• バグ修正を起点とするタスクでは、回帰テストが含まれています。
• 他のエージェントが確認なしで実行できるだけの、正確な引き継ぎ内容になっています。