# Task Planning

> 設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。

- Skill: `windschord/task-planning` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add windschord/task-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/windschord/task-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: windschord (https://skillmd.com/u/windschord)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/windschord/task-planning

---


# タスク計画スキル

設計書を基に、AIエージェント（Claude Code等）が実行可能な具体的なタスクに分解します。

## 出力先（重要）

このスキルは、タスクを **デフォルトで GitHub Issue として起票** します。1タスク = 1 Issue とし、
受入基準・TDD手順・技術仕様などの詳細はすべて Issue 本文に集約します。

| モード | 出力先 | 使う場面 |
|--------|--------|----------|
| **Issue起票（デフォルト）** | GitHub Issue（github MCPツール） | 指定がない場合は常にこちら |
| ファイル生成（オプション） | `docs/sdd/tasks/[phase]/TASK-XXX.md` | ユーザーが「ファイルで」と明示した場合のみ |

- **デフォルトは常にIssueモード**: 指定がなければ `mcp__github__*` を用いてIssue起票する（MCPの有無で出力先を変えない。ラベルが未作成なら作成する）。
- **ファイルモードへの切り替え**: ユーザーが明示的にファイル管理を希望した場合**のみ**。github MCPが利用できず起票できない場合は、フォールバックせずユーザーに状況を報告して指示を仰ぐ。

## 概要（Issueモード＝デフォルト）

このスキルは、以下を作成・管理します：
- **GitHub Issue（1タスク＝1 Issue）**: タイトル `[TASK-XXX] タイトル`、本文にタスク詳細を集約
- **ラベル**: `sdd:task`（識別）、`sdd:phase-N`（フェーズ）、`sdd:status/*`（ステータス）
- **目次**: `docs/sdd/tasks/index.md` は作成しない。**`label:sdd:task` でフィルタしたGitHub Issue一覧が目次代わり**

### Issueモデル

```text
GitHub Issues（label:sdd:task でフィルタ = タスク一覧＝目次）
├── #12  [TASK-001] ユーザー認証API   [sdd:phase-1][sdd:status/todo]
├── #13  [TASK-002] データモデル定義   [sdd:phase-1][sdd:status/todo]
├── #14  [TASK-003] API統合テスト      [sdd:phase-2][sdd:status/todo]  (依存: #12,#13)
└── ...
```

- **タイトル**: `[TASK-XXX] タスクタイトル`（TASK-XXXは設計・要件ドキュメントとの相互参照用に維持）
- **本文**: `assets/templates/task_issue_template_ja.md` のフォーマットに従う
- **ステータス**: ラベル `sdd:status/{todo|in-progress|review|blocked}`。**DONEはIssueをclose**（state_reason: completed）
- **依存関係**: 本文の「依存関係」にIssue番号で記載（例: `依存: #12`）
- **並列グループ**: ラベル `sdd:group-A` または本文に明記

### 使用するgithub MCPツール

| 操作 | ツール | 補足 |
|------|--------|------|
| Issue作成 | `mcp__github__issue_write`（method: create） | title/body/labels を指定 |
| Issue更新（ステータス・close） | `mcp__github__issue_write`（method: update） | labels付け替え、state: closed |
| タスク一覧取得 | `mcp__github__list_issues` / `mcp__github__search_issues` | `labels: ["sdd:task"]` |
| 重複確認 | `mcp__github__search_issues` | 起票前に既存タスクを確認 |

> **注**: 起票前に `mcp__github__get_me` で権限・対象リポジトリを確認する。ラベルが未作成の場合は初回起票前に作成する（テンプレートの「ラベル体系」を参照）。

## ファイルモード（オプション）のドキュメント構成

ユーザーが「ファイルで管理したい」と明示した場合のみ、従来のファイル構成を使用する：

```text
docs/sdd/tasks/
├── index.md                 # 目次・進捗サマリ
├── phase-1/
│   ├── TASK-001.md          # タスク詳細
│   └── TASK-002.md
├── phase-2/
│   ├── TASK-003.md
│   └── TASK-004.md
└── phase-3/
    └── TASK-005.md
```

## このスキルを使用する場面

### 新規作成時
- 設計書からタスクを分解したい場合
- AIエージェント向けの実装指示を作成したい場合
- TDD（テスト駆動開発）の手順を定義したい場合
- 実装の優先順位・依存関係を整理したい場合

### 既存ドキュメントの修正時
- docs/sdd/tasks/にタスクを追加・修正する場合
- タスクのステータスを更新する場合
- 依存関係や見積もりを修正する場合

## 前提条件

### 前段スキルとの連携

**docs/requirements/（requirement-management）が存在する場合**:
1. `docs/requirements/generated/traceability.md` を読み込み、対象の要求IDとユーザーストーリーを特定する
2. 各タスクが1つ以上の要求IDに対応しているか確認する
3. 逆順レビュー（タスク → 要求）を実施する

設計書は読み込まない。設計は実装時にPR本文へ記載するため、タスク計画時点では存在しない。

**docs/sdd/requirements/、docs/sdd/design/しか存在しない場合（旧構成）**:

`requirements-defining` / `software-designing` は非推奨。移行が済むまでは旧ドキュメントを読み込んでよいが、移行手順（`requirement-management/references/migration_from_sdd_ja.md`）の実施を検討する。

## AIエージェント向けタスク設計

### タスク粒度の目安

| 分類 | 作業時間 | 内容例 |
|------|----------|--------|
| シンプル | 10-20分 | 単一ファイル作成、基本関数実装、設定追加 |
| 標準 | 20-40分 | 複数ファイル、APIエンドポイント、基本テスト |
| 複雑 | 40-90分 | 複数コンポーネント統合、包括的テスト |
| 要分解 | 90分以上 | さらに小さいタスクに分解 |

### タスク定義の必須要素

```markdown
#### タスク1.1: [タスクタイトル]

**説明**:
- 対象ファイルパス: `src/components/Button.tsx`
- 実装する機能の詳細
- 使用する技術・ライブラリ

**技術的文脈**:
- フレームワーク: Next.js 14 (App Router)
- スタイリング: Tailwind CSS
- 参照すべき既存コード: `src/components/Card.tsx`

**情報の明確性**:

| 分類 | 内容 |
|------|------|
| 明示された情報 | [ユーザーから明確に指定された仕様] |
| 不明/要確認の情報 | [推測が必要な項目] |

**実装手順（TDD）**:
1. テスト作成: `src/components/Button.test.tsx`
2. テスト実行: 失敗を確認
3. テストコミット
4. 実装: テストを通過させる
5. 実装コミット

**受入基準**:
- [ ] `src/components/Button.tsx`が存在する
- [ ] TypeScriptの型定義が含まれている
- [ ] テストが3つ以上ある
- [ ] `npm test`で全テスト通過
- [ ] ESLintエラーがゼロ

**依存関係**: なし
**推定工数**: 30分（AIエージェント作業時間）
**ステータス**: `TODO`
```


## TDD（テスト駆動開発）

各タスクにTDD手順（テスト作成 → 失敗確認 → テストコミット → 実装 → 通過確認 → 実装コミット）を記載する。具体的なテストファイルパスとテストケースを明記すること。

## ワークフロー（Issueモード＝デフォルト）

### 新規作成フロー

1. **ドキュメント確認**: `docs/requirements/generated/traceability.md` を読み込み、実装対象の要求IDとストーリーを特定する（旧構成の場合は docs/sdd/requirements/）
2. **情報分類**: 明示された情報と不明な情報を分類
3. **不明点確認**: 必要な情報をユーザーに確認
4. **環境確認**: `mcp__github__get_me` で対象リポジトリ・権限を確認。ラベル（`sdd:task`等）が未作成なら作成
5. **フェーズ分け**: 作業を論理的なフェーズに分割
6. **タスク分解**: 各タスクを `assets/templates/task_issue_template_ja.md` に従って本文を構築
7. **重複確認**: `mcp__github__search_issues` で既存タスクを確認
8. **Issue起票**: `mcp__github__issue_write`（method: create）で各タスクをIssue化。タイトル `[TASK-XXX] タイトル`、ラベル `sdd:task` / `sdd:phase-N` / `sdd:status/todo` を付与
9. **依存関係整理**: 各Issue本文の「依存関係」に依存Issue番号（例: `依存: #12`）を記載。必要に応じてラベル `sdd:group-X`
10. **逆順レビュー**: タスク → 要求の整合性確認
11. **TodoWrite同期**: 起票したIssueをTodoWriteに登録（`sdd-documentation/references/task_sync_guide_ja.md` 参照）
12. **ユーザー確認**: 起票したIssue番号一覧を提示し、承認を得て完了

> **注**: 目次（index.md）は作成しない。タスク一覧は `label:sdd:task` のGitHub Issue検索で参照する。

### タスク追加フロー

1. **本文構築**: `task_issue_template_ja.md` に従い、情報の明確性・受入基準・TDD手順を記述
2. **重複確認**: `mcp__github__search_issues` で既存タスクを確認
3. **Issue起票**: `mcp__github__issue_write`（method: create）でラベル付きIssueを作成
4. **依存関係更新**: 関連タスクとの依存をIssue本文（Issue番号）で相互参照

## ワークフロー（ファイルモード＝オプション）

ユーザーが「ファイルで管理」を明示した場合のみ、従来フローを使用する：

1. **ディレクトリ作成**: `docs/sdd/tasks/` 以下にフェーズ別ディレクトリを作成
2. **index.md作成**: 目次と進捗サマリを記述（`assets/templates/tasks_index_template_ja.md`）
3. **タスク分解**: 各タスクを `[phase]/TASK-XXX.md` として作成（`assets/templates/task_detail_template_ja.md`）
4. **index.md更新**: 作成したタスクへのリンクを追加
5. **依存関係整理・逆順レビュー・TodoWrite同期・ユーザー確認**

## 逆順レビュープロセス

タスク → 要求の整合性を確認する（各タスクが要求IDに対応し、対象ストーリーの受入要求が漏れなく覆われているか）。詳細チェック項目は `sdd-documentation/references/checklist_ja.md` を参照。不整合発見時はリストアップしてユーザーに確認してから修正する。

## タスク同期（TodoWrite連携）

タスク計画完了時にTodoWriteへ同期する。ステータスマッピングと運用ルールは `sdd-documentation/references/task_sync_guide_ja.md` を参照。

## エージェントチーム向けタスク設計（必須考慮事項）

**タスク計画時は常にエージェントチームでの並列実行を前提として設計する。**並列実行可能なタスクが3つ以上になるようタスクを分割・構成することを目指す。

**注意**: 並列化のためだけにタスクを過剰に分割しないこと。各タスクの粒度（20-40分目安）を維持することを優先し、自然に3つ以上に分かれない場合は順次実行で問題ない。

### 設計原則

1. **ファイル独立性（最重要）**: 各タスクが異なるファイルセットを対象とするよう分割する。同一ファイルを複数タスクが編集する設計は禁止。
2. **並列実行グループの明示**: 並列実行可能なタスクグループを明記する（必須）。
   - **Issueモード**: ラベル `sdd:group-A` を付与し、各Issue本文の「依存関係」にグループと依存Issue番号を記載
   - **ファイルモード**: index.mdに並列実行グループ表を記載
3. **依存関係の最小化**: 可能な限り並列実行可能なタスク数を最大化する
4. **コンテキストの完全性**: 各タスクがスポーンプロンプトだけで実行できるよう、以下を必ず記載:
   - 対象ファイルの絶対パス
   - 参照すべき設計ドキュメントのパス
   - 使用する技術スタック・ライブラリ
   - テスト要件

### 並列実行グループの記載例

**Issueモード（デフォルト）**: 各Issueにラベル `sdd:group-X` を付け、本文に依存を明記。

```markdown
<!-- #12 [TASK-001] の本文「依存関係」 -->
- 並列実行: グループA（#13, #14 と並行実行可能）
- 前提Issue: なし
```

**ファイルモード（オプション）**: index.mdに並列実行グループ表を記載。

```markdown
## 並列実行グループ

### グループA（並列実行可能）
| タスク | 対象ファイル | 依存 |
|--------|-------------|------|
| TASK-001 | src/auth/** | なし |
| TASK-002 | src/api/** | なし |
| TASK-003 | src/models/** | なし |

### グループB（グループA完了後に並列実行可能）
| タスク | 対象ファイル | 依存 |
|--------|-------------|------|
| TASK-004 | src/services/auth-service.ts | TASK-001 |
| TASK-005 | src/services/api-service.ts | TASK-002 |
```

**詳細**: `sdd-documentation/references/agent_teams_guide_ja.md`

## 検証チェックリスト

- [ ] タスクが適切な粒度に分解されている（20-40分程度）
- [ ] 各タスクに受入基準がある
- [ ] 依存関係が明確である
- [ ] 推定工数が記載されている
- [ ] ステータスが有効な値である
- [ ] 各タスクの「情報の明確性」セクションが記載されている
- [ ] 推測に基づく実装指示が含まれていない
- [ ] TDD手順が含まれている
- [ ] すべてのタスクが1つ以上の要求ID（REQ-XXXX）に対応している
- [ ] 対象ストーリーの受入要求が、いずれかのタスクで覆われている
- [ ] TodoWriteにタスク一覧が同期されている
- [ ] 並列実行グループが明示されている（チーム実行時）

## ユーザーとの対話ガイドライン

### 確認が必要な場面

- タスクの粒度
- 優先順位
- 見積もり時間
- 実装の順序
- テストカバレッジの目標
- 使用するライブラリのバージョン

### サブエージェント向け情報の完全性

各タスクに以下が含まれているか確認：

**技術仕様**:
- [ ] 対象ファイルの絶対パス
- [ ] 使用するライブラリ/フレームワークのバージョン
- [ ] 関数/クラスのシグネチャ
- [ ] 型定義（TypeScriptの場合）

**実装詳細**:
- [ ] 入力の形式と型
- [ ] 出力の形式と型
- [ ] エラーケースとその処理方法

**テスト仕様**:
- [ ] テストファイルのパス
- [ ] テストケースの具体的な内容
- [ ] 期待される入出力の具体例

## リソース

### テンプレート
- **タスクIssueテンプレート（デフォルト）**: `assets/templates/task_issue_template_ja.md`
- 目次テンプレート（ファイルモード）: `assets/templates/tasks_index_template_ja.md`
- タスク詳細テンプレート（ファイルモード）: `assets/templates/task_detail_template_ja.md`

### リファレンス
- タスクガイドライン: `references/task_guidelines_ja.md`

### 命名規則

**Issueモード（デフォルト）**:

| 種別 | 命名規則 | 例 |
|------|---------|-----|
| Issueタイトル | `[TASK-XXX] タイトル` | `[TASK-001] ユーザー認証API` |
| フェーズラベル | `sdd:phase-N` | `sdd:phase-1` |
| ステータスラベル | `sdd:status/{todo\|in-progress\|review\|blocked}` | `sdd:status/todo` |

**ファイルモード（オプション）**:

| ファイル種別 | 命名規則 | 例 |
|-------------|---------|-----|
| フェーズディレクトリ | `phase-N` | `phase-1`, `phase-2` |
| タスクファイル | `TASK-XXX.md` | `TASK-001.md`, `TASK-002.md` |

### タスクIDの採番ルール
- プロジェクト全体で一意のIDを割り当て
- フェーズをまたいでも連番を維持
- 例: Phase 1で TASK-001〜003、Phase 2で TASK-004〜 と続ける