---
name: sdd-task-planning
description: "承認済みの設計（軽量では要点）から、依存順のタスク、確認方法、完了の条件をタスク一覧（tasks.md）にまとめるときに使う。"
user-invocable: true
---

# タスク分解

入力: 標準では承認済みの設計文書 `docs/spec/current/design/<機能>.md`（外部設計・内部設計の部）と要件文書の受入条件、軽量では `outline.md` と変更した要件（窓口から渡されたパスと ID）。

1. 次の節だけを読む。内部設計の構成・コンポーネント（§2・§4）、処理（§5）、データ（§6）、連携（§7）、非機能・運用（§8）、テスト設計（§9）、変更影響・未解決質問（§10）。外部設計の要件対応・確認事項（§5）。要件文書の受入条件。軽量では `outline.md` 全体。設計で採用した ADR は、タスクの前提になるときだけ読む。新しい要件や設計にないことが必要なら、タスクを足さずに窓口へ返す。
2. 期限が実装の未解決質問が残っていれば、タスクを作らずに窓口へ返す。
3. `docs/spec/changes/<ID>/tasks.md` を作る（作るときだけ [テンプレート](templates/tasks.md) を読む）。各タスクに、内容（何をするか・編集する範囲・完了の条件）、対応する要件・受入条件の ID、設計 ID、確認方法を書く。範囲は内部設計 §4 の配置（軽量では要点の「変える箇所」）から、編集するファイル・ディレクトリを書く。設計 ID がないタスク（軽量、文書だけの変更）は「—」とする。状態は `todo`。
4. 内部設計 §2 の依存の向き（内側の層から）と §10 の移行の順に従って、依存順に並べる。
5. 確認方法は内部設計 §9 のテスト設計と外部設計 §5 の確認観点（軽量では要点の「テスト」）から決める。振る舞いのタスクは TDD（実行するテストのコマンド）、文書・設定のタスクはレビューや設定の検証にする。手動の確認が必要なら、その手順を書く。
6. すべての受入条件がどれかのタスクの確認でカバーされ、承認済みの設計 ID がどれかのタスクに対応しているか確かめる。抜けは出力に示す。
7. [sdd-spec-check](../sdd-spec-check/SKILL.md)（変更 ID 付き）でタスク一覧の形式を確かめる。タスク分解には承認を置かない。

停止: 要件・設計が足りない、新しい要件が必要、期限が実装の質問が未回答。

出力: タスク一覧、受入条件・設計 ID との対応の抜け、質問。