tasks.md を読み込み、未完了タスクを分析してバッチ実行計画を立てよ。

**注意:** Previous Responseがある場合は前回バッチの完了後の再計画である。
tasks.md のチェック状況を確認し、次のバッチを決定せよ。

**やること:**
1. 対象feature名を特定する
   - 初回（00-plan.md がない）: User Task から feature 名を抽出する
   - 再計画（00-plan.md がある）: 既存 00-plan.md の「## 対象feature」を優先する
   - 特定できない場合は「要件が不明確、情報不足」と判定する
2. `.kiro/specs/{feature}/spec.json` を読み込み、`approvals.tasks.generated` が `true` であることを確認する。そうでなければ「tasks.mdが存在しない、または空」と判定する
3. `tasks_path = .kiro/specs/{feature}/tasks.md` を確定する
4. `{tasks_path}` を読み込む
   - ファイルが存在しない場合は「tasks.mdが存在しない、または空」と判定する
   - ファイルが空、またはタスク（`- [ ]` / `- [x]` / `- [X]`）が1つもない場合も同様
5. 未完了タスク（`- [ ]`）を特定する
6. 全タスクが完了済み（`- [x]` または `- [X]`）の場合、「全タスク完了」と判定する
7. 未完了タスクがある場合:
   a. 各タスクの実装スコープを見積もる（変更ファイル数・複雑さ）
   b. コードを調査し、影響範囲を特定する
   c. バッチを決定する:
      - 同じファイルを触るタスクは同一バッチに集約
      - 1バッチは関連ソースコードがコンテキストに収まる範囲に制限
8. 実装アプローチを決める
   - ナレッジ・ポリシーの制約に違反しないか照合する

**バッチサイズの判定基準（両方の条件を満たすこと）:**

条件1: コンテキスト上限（関連コードがコンテキストに収まる最大タスク数）
- Small（1-2ファイル変更）: 最大8タスク
- Medium（3-5ファイル変更）: 最大3タスク
- Large（6+ファイル変更）: 最大1タスク

条件2: 最低作業量（起動オーバーヘッドを償却するための下限）
- 1バッチの推定作業時間が5分以上になるようタスクをまとめる
- Smallタスクのみの場合は最低3タスクを1バッチに含める
- 未完了タスクが下限に満たない場合は、残り全てを1バッチにまとめる

**必須出力:**

```markdown
# バッチ実行計画

## 対象feature
- feature: {feature}
- tasks_path: `.kiro/specs/{feature}/tasks.md`

## 進捗
- 完了: {完了タスク数}/{全タスク数}
- 未着手: {未着手タスク数}

## 今回のバッチ
| タスクID | タスク概要 |
|----------|-----------|
| X.X | ... |

## 実装アプローチ
{バッチ内タスクの実装方針}

## 実装ガイドライン
- {Coderが従うべきガイドライン}
- 並行可能なタスクがある場合、CLIエージェントの内部並行処理機能を活用してよい
```
