タスク計画スキル
設計書を基に、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モデル
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で権限・対象リポジトリを確認する。ラベルが未作成の場合は初回起票前に作成する(テンプレートの「ラベル体系」を参照)。
ファイルモード(オプション)のドキュメント構成
ユーザーが「ファイルで管理したい」と明示した場合のみ、従来のファイル構成を使用する:
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/sdd/requirements/、docs/sdd/design/が存在する場合:
- 両方のドキュメントを読み込む
- タスクが設計・要件と整合しているか確認
- 逆順レビュー(タスク → 設計 → 要件)を実施
AIエージェント向けタスク設計
タスク粒度の目安
| 分類 | 作業時間 | 内容例 | |------|----------|--------| | シンプル | 10-20分 | 単一ファイル作成、基本関数実装、設定追加 | | 標準 | 20-40分 | 複数ファイル、APIエンドポイント、基本テスト | | 複雑 | 40-90分 | 複数コンポーネント統合、包括的テスト | | 要分解 | 90分以上 | さらに小さいタスクに分解 |
タスク定義の必須要素
#### タスク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モード=デフォルト)
新規作成フロー
- ドキュメント確認: docs/sdd/requirements/、docs/sdd/design/を読み込む
- 情報分類: 明示された情報と不明な情報を分類
- 不明点確認: 必要な情報をユーザーに確認
- 環境確認:
mcp__github__get_meで対象リポジトリ・権限を確認。ラベル(sdd:task等)が未作成なら作成 - フェーズ分け: 作業を論理的なフェーズに分割
- タスク分解: 各タスクを
assets/templates/task_issue_template_ja.mdに従って本文を構築 - 重複確認:
mcp__github__search_issuesで既存タスクを確認 - Issue起票:
mcp__github__issue_write(method: create)で各タスクをIssue化。タイトル[TASK-XXX] タイトル、ラベルsdd:task/sdd:phase-N/sdd:status/todoを付与 - 依存関係整理: 各Issue本文の「依存関係」に依存Issue番号(例:
依存: #12)を記載。必要に応じてラベルsdd:group-X - 逆順レビュー: タスク → 設計 → 要件の整合性確認
- TodoWrite同期: 起票したIssueをTodoWriteに登録(
sdd-documentation/references/task_sync_guide_ja.md参照) - ユーザー確認: 起票したIssue番号一覧を提示し、承認を得て完了
注: 目次(index.md)は作成しない。タスク一覧は
label:sdd:taskのGitHub Issue検索で参照する。
タスク追加フロー
- 本文構築:
task_issue_template_ja.mdに従い、情報の明確性・受入基準・TDD手順を記述 - 重複確認:
mcp__github__search_issuesで既存タスクを確認 - Issue起票:
mcp__github__issue_write(method: create)でラベル付きIssueを作成 - 依存関係更新: 関連タスクとの依存をIssue本文(Issue番号)で相互参照
ワークフロー(ファイルモード=オプション)
ユーザーが「ファイルで管理」を明示した場合のみ、従来フローを使用する:
- ディレクトリ作成:
docs/sdd/tasks/以下にフェーズ別ディレクトリを作成 - index.md作成: 目次と進捗サマリを記述(
assets/templates/tasks_index_template_ja.md) - タスク分解: 各タスクを
[phase]/TASK-XXX.mdとして作成(assets/templates/task_detail_template_ja.md) - index.md更新: 作成したタスクへのリンクを追加
- 依存関係整理・逆順レビュー・TodoWrite同期・ユーザー確認
逆順レビュープロセス
タスク → 設計 → 要件の整合性を確認する。詳細チェック項目は sdd-documentation/references/checklist_ja.md を参照。不整合発見時はリストアップしてユーザーに確認してから修正する。
タスク同期(TodoWrite連携)
タスク計画完了時にTodoWriteへ同期する。ステータスマッピングと運用ルールは sdd-documentation/references/task_sync_guide_ja.md を参照。
エージェントチーム向けタスク設計(必須考慮事項)
**タスク計画時は常にエージェントチームでの並列実行を前提として設計する。**並列実行可能なタスクが3つ以上になるようタスクを分割・構成することを目指す。
注意: 並列化のためだけにタスクを過剰に分割しないこと。各タスクの粒度(20-40分目安)を維持することを優先し、自然に3つ以上に分かれない場合は順次実行で問題ない。
設計原則
- ファイル独立性(最重要): 各タスクが異なるファイルセットを対象とするよう分割する。同一ファイルを複数タスクが編集する設計は禁止。
- 並列実行グループの明示: 並列実行可能なタスクグループを明記する(必須)。
- Issueモード: ラベル
sdd:group-Aを付与し、各Issue本文の「依存関係」にグループと依存Issue番号を記載 - ファイルモード: index.mdに並列実行グループ表を記載
- Issueモード: ラベル
- 依存関係の最小化: 可能な限り並列実行可能なタスク数を最大化する
- コンテキストの完全性: 各タスクがスポーンプロンプトだけで実行できるよう、以下を必ず記載:
- 対象ファイルの絶対パス
- 参照すべき設計ドキュメントのパス
- 使用する技術スタック・ライブラリ
- テスト要件
並列実行グループの記載例
Issueモード(デフォルト): 各Issueにラベル sdd:group-X を付け、本文に依存を明記。
<!-- #12 [TASK-001] の本文「依存関係」 -->
- 並列実行: グループA(#13, #14 と並行実行可能)
- 前提Issue: なし
ファイルモード(オプション): index.mdに並列実行グループ表を記載。
## 並列実行グループ
### グループ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手順が含まれている
- [ ] すべてのタスクがdesign/のコンポーネント/APIに対応している
- [ ] すべての設計要素がrequirements/に対応している
- [ ] 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〜 と続ける