---
name: manage-plan-todos
description: |
  docs/plan.md内のTODOリストを管理します。TODO項目の追加、完了マーク、整理を行います。
  ユーザーがplan.mdの更新、TODO管理、計画の進捗確認を依頼したときに使用してください。
  プロジェクト固有のTODO形式ルール（フラット構造、エピック化など）を遵守します。
allowed-tools: Read, Edit
---

# Plan TODOリスト管理スキル

このスキルはdocs/plan.md内のTODOリストを、プロジェクト固有のルールに従って管理します。

## プロジェクト固有のルール

docs/plan.mdには以下のNOTICEが記載されており、厳格に守る必要があります：

> NOTICE: TODOリストはフラットな箇条書きで、着手順に上から並べること。新しい項目もフラットに、実施順になるよう途中に挿入する。セクションを分けたり階層化するのは禁止。

### フラット構造の利点

- **シンプル**: 構造がシンプルで理解しやすい
- **柔軟性**: タスクの順序変更が容易
- **可視性**: 全体が一目で把握できる
- **メンテナンス性**: 構造の維持が簡単

階層化すると、リストが複雑になり、全体像が見えにくくなり、頻繁な再編成が必要になります。

### エピック vs 詳細タスク

**エピック（遠い将来）**: 大まかなまとまりとして1項目で記述
```markdown
- [ ] YAMLでワークフローを設定可能にする
- [ ] ワークフローグラフ可視化機能を追加
```

理由：
- リストが長くなりすぎるのを防ぐ
- 詳細が変わる可能性が高い（早期の詳細化は無駄）
- 着手時に最新の状況に基づいて詳細化できる

**詳細タスク（近い将来）**: 具体的に記述
```markdown
- [ ] worker.tsでLLM呼び出し時にプロンプトとレスポンスをDynamoDBに保存（type: 'llm_call'）
- [ ] App.tsxでLLM呼び出しログを表示するUI追加（折りたたみ可能）
```

理由：
- すぐに着手するため具体性が必要
- 実装の詳細が明確
- チーム全員が何をすべきか理解できる

**エピックの詳細化タイミング**: 着手が近づいた時（次の1-3ステップ以内）、要件が明確になった時、設計が固まった時

### タスク記述のルール

1. **接頭辞不要**: "Step 1-1"などの接頭辞は不要。内容だけを記述
2. **動詞で始める**: 「実装」「追加」「修正」など
3. **動作確認省略**: 各タスク完了時に当然行われるため、明示的な項目は不要
4. **括弧で詳細追記**: 必要に応じてファイル名や技術詳細を括弧で追記

### 完了タスクの管理

完了したタスクは`[x]`でマークする。作業が一区切りついたら、レビューしながらまとめて`### Done`セクションに移動：

```markdown
## TODOリスト
- [x] 完了したタスク
- [x] 完了したタスク
- [ ] 未完了タスク
- [ ] 未完了タスク
- [ ] 未完了タスク

### Done
- [x] 以前に完了したタスク
- [x] 以前に完了したタスク
- [x] 以前に完了したタスク
- [x] 以前に完了したタスク
```

### 新規タスクの挿入

末尾に追加するのではなく、実施順になるよう適切な位置に挿入：

Before:
```markdown
- [ ] タスクA（今すぐ）
- [ ] タスクB（次）
- [ ] タスクC（後で）
```

After
```markdown
- [ ] タスクA（今すぐ）
- [ ] タスクB（次）
- [ ] タスクD ← タスクBとCの間に挿入
- [ ] タスクC（後で）
```

## 使用シナリオ

### TODOの追加
- 新しいタスクを適切な位置（実施順）に挿入
- フラット構造を維持
- 近い将来のタスクは具体的に、遠い将来のタスクはエピックとして記述

### TODOの完了マーク
- `- [ ]` を `- [x]` に変更
- 完了した項目は `### Done` セクションに移動

### TODOの整理
- 実施順序に従って並び替え
- エピックを詳細化する（着手が近づいた時）
- フラット構造を維持

### 進捗確認
- 現在のTODOリストの状態を報告
- 完了済み項目数と未完了項目数を集計
- 次に着手すべき項目を提案

## 作業フロー

1. **読み込み**: docs/plan.md の TODOセクションを読む
2. **ルール確認**: NOTICE記載のルールを確認
3. **変更提案**: フラット構造を維持しながら変更内容を提案
4. **実行**: ユーザーの承認後、Editツールで変更を適用

## 例

### 良い例：フラット構造

```markdown
## TODOリスト

- [ ] worker.tsでLLM呼び出しログを保存
- [ ] App.tsxでログ表示UI追加
- [ ] 2つ目のLLM呼び出しを追加
- [ ] 2つのLLMが並列実行されるように実装
- [ ] YAMLでワークフローを設定可能にする（エピック）
- [ ] IAM リソース絞り込み
```

### 悪い例：階層化・セクション分割

```markdown
## TODOリスト

### Step 1: ログ可視化
- [ ] Step 1-1: worker.tsでLLM呼び出しログを保存
- [ ] Step 1-2: App.tsxでログ表示UI追加
- [ ] Step 1-3: ブラウザで動作確認

### Step 2: 並列実行
- [ ] Step 2-1: 2つ目のLLM呼び出しを追加
```

## ユーザー依頼例

- 「plan.mdのTODOを確認して」
- 「新しいタスクをTODOリストに追加して」
- 「完了したタスクをマークして」
- 「次のマイルストーンのタスクを整理して」