TDD開発でテストケースの実装が完全に完了しているかを検証します。

context

出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} メモファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md テストケースファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md 元タスクファイル=docs/tasks/{taskfile}.md

step

• $ARGUMENTS がない場合、「引数に要件名とTASK-IDを指定してください（例: ユーザー認証機能 TASK-0001）」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2: コンテキスト準備

検証コンテキストの準備を実行する：

1. 既存の実装ドキュメントの確認

   • ./docs/implements/{要件名}/{{task_id}}/ ディレクトリ内の全てのMDファイルを確認
   • 特に以下のファイルを優先的に読み込み：
     • note.md - タスクノート（技術スタック、開発ルール、関連実装）
     • {feature_name}-requirements.md - 要件定義
     • {feature_name}-testcases.md - テストケース定義
     • {feature_name}-refactor-phase.md - Refactorフェーズの結果
     • {feature_name}-memo.md - 開発履歴メモ
     • その他の関連MDファイル
   • これらのファイルから既存の実装状況、設計判断、注意事項を把握

2. 追加ルールの読み込み

   • AGENTS.md ファイルが存在する場合は読み込み
   • ./docs/rule ディレクトリが存在する場合は読み込み
   • ./docs/rule/tdd ディレクトリが存在する場合は読み込み
   • ./docs/rule/tdd/verify-complete ディレクトリが存在する場合は読み込み
   • 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用

3. @agent-symbol-searcher で検証関連情報を検索し、見つかったファイルを読み込み

   • 完了予定のテストケースや機能を検索し、該当ファイルをReadツールで読み込み
   • 既存のテストカバレッジや品質基準を確認し、関連ファイルをReadツールで読み込み
   • 実装完了タスクのマーキングパターンを特定し、タスクファイルをReadツールで読み込み

4. 元タスクファイルを直接読み込み

   • docs/tasks/{taskfile}.md - タスクの完了状態を確認
   • プロジェクト全体のタスク進捗を把握

読み込み完了後、step3 を実行する

step3: 既存テストのグリーン状態確認

• 必須: @task で全ての既存テストが成功していることを確認
• テスト失敗がある場合: memoファイルに記載し、後の工程で修正対応することを記録
• この工程では修正禁止: テスト失敗を発見してもここでは修正しない
• テスト状態を記録し、step4 に進む

step4: 実装状況の分析

• 現在のテストファイルを確認
• 実装済みテストケース数をカウント
• 各テストケースの内容を予定（テストケース定義ファイル）と照合
• <analysis_format> の形式で分析結果を提供する
• 品質判定基準に基づいて合否判定を行う
• step5 を実行する

step5: 検証結果のメモファイル記録

• {{メモファイル}} の既存内容を整理・統合し、<memo_format> の形式で更新
• 統合更新ルールに従って、重要情報を保持し重複を削除
• 実装パターン、テスト設計、品質保証の学習ポイントを記録
• 修正が必要な項目がある場合、後工程での対応方針を記載して step7 を実行する
• 修正が必要ない場合、step6 を実行する

step6: 元タスクファイル完了マーク更新

検証が完了した場合、以下の手順で元タスクファイルを自動更新：

1. 完了タスクの特定: 現在のTDD開発対象タスクを元タスクファイルから特定
2. 完了マーク追加: 該当タスクに ✅ **完了** マークを追加
3. 完了理由記載: (TDD開発完了 - [テスト数]テストケース全通過) を追記
4. サブタスク更新: 関連するサブタスクにも [x] チェックマークを追加

例：

### 1. JSONファイルパス引数処理機能 ✅ **完了** (TDD開発完了 - 15テストケース全通過)

- [x] コマンドライン引数でJSONファイルパスを受け取る機能を追加
- [x] 複数のJSONファイルパスに対応（sample/ディレクトリ全体の読み込み）
- [x] 引数バリデーション機能

step7 を実行する

step7: TODO更新と次ステップ判定

• TodoWrite ツールで TODO ステータスを更新する

  • 現在のTODO「検証フェーズ（完全性確認）」を「completed」にマーク
  • 検証結果をTODO内容に反映
  • 品質判定結果をTODO内容に記録

• 完全実装済み判定: 以下の条件を満たす場合は 完全実装済み とする

  • 既存テスト状態: すべてグリーン
  • 要件網羅率: 100%（全要件項目実装・テスト済み）
  • テスト成功率: 100%
  • 未実装重要要件: 0個

• 完全実装済みの場合: <complete_output> の形式で出力し、次のステップを提案

• 実装不足がある場合: <incomplete_output> の形式で出力し、状況を報告

rules

検証の原則

• この工程では修正を行わない
• この検証フェーズではコードやテストの修正は一切行わない
• 問題を発見した場合は内容をmemoファイルに記載する
• 修正作業は後の工程（次のTDDサイクルや別のタスク）に委ねる
• 検証・記録・報告に専念する
• テストの実行は @task で実行する

禁止事項（NEVER）

• コードやテストの修正禁止
• 新規実装の追加禁止
• テストケースの削除・変更禁止
• 全体のテストケースの実装率と成功率のレポートは省略禁止

品質基準

最低品質基準

• 実装率: 80%以上
• 成功率: 100%
• 重要テスト: すべて実装
• 要件網羅性: 要件定義書の主要機能をすべて網羅
• コンパイルエラー: なし

理想品質基準

• 実装率: 100%
• 成功率: 100%
• 網羅性: 全ケース対応
• 要件完全網羅: 要件定義書の全項目を網羅

品質判定基準

✅ 高品質（要件充実度完全達成）:
- 既存テスト状態: すべてグリーン
- 要件網羅率: 100%（要件定義書の全項目に対する完全な実装・テスト）
- テスト成功率: 100%
- 未実装重要要件: 0個
- 要件充実度: 要件定義に対する完全な充実度を達成

⚠️ 要改善（要件充実度不足）:
- 既存テスト状態: 失敗テストあり または
- 要件網羅率: 100%未満（要件定義書の項目に対する実装・テスト不足）
- 重要な要件項目が未実装・未テスト
- 要件充実度: 要件定義に対する充実度が不十分
- 追加実装による要件充実度向上が必要

ファイルパスの記載ルール

• プロジェクトルートを基準とした相対パスを使用する
• フルパス（絶対パス）は記載しない
• 例:
  • ❌ /Users/username/projects/myapp/src/utils/helper.ts
  • ✅ src/utils/helper.ts

info

<analysis_format>

テストケース実装状況

📋 TODO.md対象タスク確認

• 対象タスク: [現在のTDD開発対象タスク名]
• 現在のステータス: [未完了/部分完了/完了済み]
• 完了マーク要否: [要/不要]

📋 予定テストケース（要件定義より）

• 総数: [予定していた総テストケース数]
• 分類:
  • 正常系: [数]個
  • 異常系: [数]個
  • エッジケース: [数]個
  • その他: [数]個

✅ 実装済みテストケース

• 総数: [実装済み総テストケース数]
• 成功率: [通過テスト数]/[実装テスト数] ([成功率]%)

❌ 未実装テストケース（[数]個）

1. テストケース名: [予定していたが未実装のテスト]

   • 種類: [正常系/異常系/エッジケース]
   • 内容: [テストの詳細内容]
   • 重要度: [高/中/低]
   • 要件項目: [対応する要件定義書の項目]

2. テストケース名: [2つ目の未実装テスト] ...

📋 要件定義書網羅性チェック

• 要件項目総数: [要件定義書の総項目数]
• 実装済み項目: [実装・テスト済みの項目数]
• 要件網羅率: [実装済み]/[総数] = [網羅率]%

未網羅の要件項目（[数]個）

1. 要件項目: [未実装の要件項目名]

   • 分類: [入力パラメータ/出力仕様/制約条件/使用例/エラーケース等]
   • 内容: [要件の詳細内容]
   • 実装不足の理由: [なぜ未実装なのか]
   • 対応の必要性: [必須/推奨/任意]

2. 要件項目: [2つ目の未網羅項目] ...

📊 実装率

• 全体実装率: [実装数]/[予定数] = [実装率]%
• 正常系実装率: [実装数]/[予定数] = [実装率]%
• 異常系実装率: [実装数]/[予定数] = [実装率]%
• エッジケース実装率: [実装数]/[予定数] = [実装率]%

要件定義書の網羅性チェック

要件定義書（requirements.md）に記載された以下の項目が実装・テストされているかを確認：

必須チェック項目

• 入力パラメータ: 全ての必須・オプション引数の処理
• 出力仕様: 期待される出力形式・構造の実装
• 制約条件: パフォーマンス・セキュリティ・互換性要件
• 基本使用例: 想定される基本的な使用パターン
• エッジケース: 境界値・例外条件の処理
• エラーケース: 異常系の適切な処理
• 主要アルゴリズム: 機能の核となる処理ロジック

網羅性判定基準

✅ 完全網羅 (100%):
- 要件定義書の全項目が実装・テストされている
- 入力パラメータの全パターンをテスト
- 出力仕様の全形式を検証
- エラーケース・エッジケースを全て網羅

⚠️ 部分網羅 (80-99%):
- 主要機能は実装されているが一部項目が未実装
- 基本的な使用例は網羅されている
- 重要でないエラーケースの一部が未実装

❌ 不十分 (<80%):
- 要件定義書の重要な項目が未実装
- 基本的な使用例に漏れがある
- エラーハンドリングが不十分

</analysis_format>

<memo_format>

[機能名] TDD開発完了記録

確認すべきドキュメント

• docs/tasks/{taskファイルのパス}.md
• docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md
• docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md

🎯 最終結果 ([日時])

• 実装率: [数]% ([実装数]/[予定数]テストケース)
• 品質判定: [合格/不合格]
• TODO更新: [✅完了マーク追加/要改善]

💡 重要な技術学習

実装パターン

[今後再利用できる重要な実装手法]

テスト設計

[効果的だったテストアプローチ]

品質保証

[品質確保で重要だった観点]

⚠️ 注意点・修正が必要な項目（該当時のみ）

[実装時の重要な注意事項や未完了項目]

🔧 後工程での修正対象

テスト失敗

• [失敗しているテストケース名]
• 失敗内容: [具体的な失敗内容]
• 修正方針: [推奨される修正方法]

実装不足

• [未実装の機能や要件]
• 不足内容: [具体的な不足内容]
• 対応方針: [推奨される対応方法]

品質改善

• [品質向上が必要な箇所]
• 改善内容: [具体的な改善内容]
• 改善方針: [推奨される改善方法]

---

既存のメモ内容から重要な情報を統合し、重複・詳細な経過記録は削除

統合更新ルール

1. 重要情報保持: 既存メモの技術的学習ポイント・再利用可能パターンを統合
2. 重複削除: 類似の記録・詳細な経過は最新情報に集約
3. 簡潔化: 日付・数値などの詳細は最終結果のみ保持
4. 再利用重視: 今後の開発で参考になる情報を優先して残す
5. 関連情報重視: 仕様情報などの情報は優先して残す </memo_format>

<complete_output> ✅ テストケース完全性検証: 合格

📊 今回のタスク要件充実度:

• 対象要件項目: [数]個
• 実装・テスト済み: [数]個 / 未実装: [数]個
• 要件網羅率: 100%
• 要件充実度: 完全達成

📊 全体のテスト状況:

• 全テストケース総数: [数]個
• 成功: [数]個 / 失敗: [数]個
• 全体テスト成功率: [数]%

🚀 要件定義に対する完全な充実度を達成しました。 自動で次のTDDサイクルに進みます。

次のお勧めステップ: /tsumiki:tdd-cycle で次のTDDサイクルを開始します。 </complete_output>

<incomplete_output> ⚠️ テストケース実装不足を検出

📊 今回のタスク要件充実度:

• 対象要件項目: [数]個
• 実装・テスト済み: [数]個 / 未実装: [数]個
• 要件網羅率: [数]%
• 要件充実度: [充実度レベル]

📊 全体のテスト状況:

• 全テストケース総数: [数]個
• 成功: [数]個 / 失敗: [数]個
• 全体テスト成功率: [数]%

❌ 未実装テストケース: [未実装テストケースの詳細リスト]

📝 修正内容をmemoファイルに記録済み 後の工程で対応予定です。この工程では修正を行いません。 </incomplete_output>