task-decomposer

タスク分解

曖昧な機能リクエストを、具体的で実装可能なタスクの順序に変換します。 受け入れ基準を特定し、トレーサーバレット型の垂直スライスに分解して工数を見積もり、 依存関係と並列化を整理し、エッジケースを列挙し、テストを計画し、HITL／AFK 対応状況をラベル付けし、 リスクにフラグを付け、すぐに実行できるタスクボードを作成します。

このスキルと標準の分解を使い分ける場面： 基盤モデルは、アドホックな形式で機能を適切に分解できます。このスキルは、依存関係のマッピング、並列化フラグ、リスクフラグ、統合テスト戦略を含む、フェーズ別のタスク表という構造化された出力が必要な場合に使用してください。手順の簡単なリストだけが必要な場合は、このスキルを呼び出さずに直接依頼してください。

参照ファイル

ファイル	内容	読み込むタイミング
references/decomposition-patterns.md	機能からタスクへの分解戦略、粒度のガイドライン	常に
references/edge-case-checklist.md	ドメイン別（Web、API、データ、CLI）の一般的なエッジケース分類	エッジケースの特定が必要なとき
references/dependency-mapping.md	依存関係グラフの作成、クリティカルパスの特定	複数タスクへの分解
references/sizing-guide.md	工数見積もりのガイダンス（S／M／L）、複雑さを示す指標	工数の見積もりが必要なとき

前提条件

• 機能の説明または要件（曖昧でもかまいません。このスキルが曖昧さに対応します）
• プロジェクトのコンテキスト（技術スタック、既存アーキテクチャ、チームの規模）

プロジェクトのコンテキスト

分解を始める前に、リポジトリ内のエージェント向けコンテキストを確認します。

• docs/agents/domain.md で CONTEXT.md、CONTEXT-MAP.md、ADR の参照ルールを確認します
• docs/agents/triage-labels.md で、タスクを課題にするときの準備状況ラベルを確認します
• タスクのタイトルと受け入れ基準には、CONTEXT.md または関連するコンテキスト内の用語集を使用します
• スコープに影響する可能性のある、長期的に適用される却下事項がないか .out-of-scope/ を確認します

これらのファイルが存在しない場合も続行しますが、推定した用語を使って計画を作成していることを明記してください。

ワークフロー

フェーズ 1：機能を理解する

1. ユーザーにとっての目標を抽出する — この機能によって、ユーザーは何ができるようになりますか？ 不明確な場合は、前提を明示します。
2. 受け入れ基準を定義する — この機能が「完了」となるには、何が満たされている必要がありますか？ 「ユーザーは X できる」「Z の場合、システムは Y を実行する」のように、テスト可能な記述で表します。
3. 非機能要件を特定する — パフォーマンス、セキュリティ、アクセシビリティ、 後方互換性に関する制約を確認します。
4. スコープの境界を明確にする — 明示的に対象外となるものは何ですか？実装中のスコープクリープを 防ぐため、これを明記します。

フェーズ 2：垂直スライスに分解する

まず機能をトレーサーバレットスライスに分解し、その後、大きすぎるスライスをタスクに分割します。 各スライスは、影響を受けるレイヤーを通る、範囲が狭くても完結した経路を提供する必要があります。 純粋なインフラ作業でない限り、ある課題ではスキーマだけを作成し、別の課題では API だけを作成し、さらに別の課題では UI だけを作成するような、水平方向の分解は避けてください。

粒度	規模	例
大まかすぎる	「検索機能を構築する」	実行可能な内容ではない
適切な粒度	「完全一致の商品検索がエンドツーエンドで結果を返す」	単一の PR でテスト可能
細かすぎる	「検索ライブラリをインポートする」	それ単独では意味がない

適切な粒度の確認基準： 各タスクは単一の PR で完了でき、単独でテストでき、独立して提供できる必要があります。完了した垂直スライスは、無関係なスライスを待たずにデモまたは検証できる必要があります。

タスクをフェーズにまとめます。

フェーズ	目的	含まれるもの
セットアップ	スライスを進めるための共有契約またはマイグレーション	型、スキーマ、フィクスチャ
スライス 1	最初のエンドツーエンドの動作	最小限のデータ、ロジック、API、UI／CLI の経路
スライス N	段階的な機能追加	ユーザーに見える動作または運用上の機能を 1 つ
品質強化	スライスをまたぐエッジケースと品質ゲート	パフォーマンス、セキュリティ、ドキュメント、クリーンアップ

各スライスにラベルを付けます。

• AFK — エージェントが、追加の人間による情報なしに、課題の概要から実装できるものです。
• HITL — 人間の判断、外部アクセス、製品の承認、デザインレビュー、またはリリース権限が必要なものです。

フェーズ 3：エッジケースを特定する

各タスクについて、エッジケースを列挙します。

1. 入力の境界 — 空、null、最大サイズ、特殊文字
2. 状態遷移 — 同時変更、中断された操作
3. エラー条件 — ネットワーク障害、無効なデータ、権限拒否
4. 後方互換性 — 既存データ、既存の API 利用者

フェーズ 4：テストを計画する

各タスクについて、テストする内容を特定します。

テストレベル	テスト内容	作成者
単体	個々の関数、純粋なロジック	実装中
統合	コンポーネント間の連携、API エンドポイント	統合フェーズ後
手動	ユーザーフロー、見た目の正確さ	仕上げフェーズ後

フェーズ 5：依存関係を整理する

どのタスクが他のタスクに依存するかを特定します。

1. 強い依存関係 — タスク B はタスク A の成果物を必要とします（クエリを書く前にデータベーステーブルが存在している必要があります）
2. 弱い依存関係 — タスク B はタスク A があると有利ですが、スタブを使うこともできます
3. 依存関係なし — タスクを並行して実施できます

フェーズ 6：リスクにフラグを付ける

各リスクについて、軽減策を特定します。

リスクの種類	例	軽減策
技術的な未知要素	「WebSockets を使ったことがない」	まずスパイク／プロトタイプを作成する
外部依存関係	「利用できない API アクセスが必要」	早めにリクエストし、モックを使う
スコープの不確実性	「要件が変わる可能性がある」	まずコアを実装し、エッジケースは後回しにする
パフォーマンスリスク	「100 万行では遅くなる可能性がある」	ベンチマークタスクを追加し、許容可能な閾値を定める

出力形式

## Task Decomposition: {Feature Name}

### Feature Summary
{One paragraph describing what this feature does and why}

### Acceptance Criteria
- [ ] {Testable statement 1}
- [ ] {Testable statement 2}
- [ ] {Testable statement 3}

### Scope
- **In scope:** {what's included}
- **Out of scope:** {what's excluded}

### Task Breakdown

#### Phase 1: Foundation
| # | Slice / Task | Type | Effort | Dependencies | Parallel |
|---|--------------|------|--------|--------------|----------|
| 1.1 | {task description} | {AFK/HITL} | {S/M/L} | None | Yes |
| 1.2 | {task description} | {AFK/HITL} | {S/M/L} | 1.1 | No |

#### Phase 2: Vertical Slices
| # | Slice / Task | Type | Effort | Dependencies | Parallel |
|---|--------------|------|--------|--------------|----------|
| 2.1 | {end-to-end behavior} | {AFK/HITL} | {S/M/L} | 1.x | Yes |
| 2.2 | {end-to-end behavior} | {AFK/HITL} | {S/M/L} | 1.x | Yes |

#### Phase 3: Hardening
| # | Task | Type | Effort | Dependencies | Parallel |
|---|------|------|--------|--------------|----------|
| 3.1 | {cross-slice quality gate} | {AFK/HITL} | {S/M/L} | 2.x | No |

### Edge Cases

| # | Edge Case | Handling | Phase |
|---|-----------|----------|-------|
| 1 | {edge case} | {how to handle} | {which phase} |

### Test Strategy

#### Unit Tests
- {Component}: {what to test}

#### Integration Tests
- {Flow}: {what to test}

#### Manual Verification
- {Scenario}: {what to check}

### Risk Flags
- {Risk}: {mitigation strategy}

### Agent Brief Notes
- {Any interface contracts, acceptance criteria, or out-of-scope boundaries that should be copied into ready-for-agent issues}

キャリブレーションのルール

1. 適切な粒度。 各スライスは1～3日分の作業とし、各実装タスクは1つのPRに収まるようにします。大きすぎる場合は、さらに分割します。小さすぎる場合は、親スライスにまとめます。
2. テスト可能な受け入れ基準。 「検索を機能させる」ではテストできません。「100文字以下のクエリに対して、検索が200ms以内に関連性の高い結果を返す」はテスト可能です。
3. 依存関係は厳守します。 タスクBが本当にタスクAに依存している場合は、そのように明記します。誤った依存関係はチームの進行を遅らせ、依存関係の見落としは統合時の失敗につながります。
4. エッジケースは必須です。 どの機能にもエッジケースがあります。エッジケースのリストが空なら、分析は不完全です。
5. 並列化は速度につながります。 並列で進められるタスクを最大化します。4つのタスクを同時に進められる場合、フェーズの所要時間は合計ではなく、最も長いタスクの時間になります。
6. まず垂直に分割します。 レイヤー単位のタスクより、エンドツーエンドのスライスを優先します。水平タスクは、スライスの進行を実際に可能にする共有コントラクト、移行、インフラストラクチャに限って使用します。
7. エージェントに任せるにはブリーフが必要です。 AFK スライスでは、望ましい動作、主要なインターフェース、受け入れ基準、対象範囲外の境界を、新しいエージェントにも明確に伝わるようにします。

エラー処理

問題	解決方法
機能の説明が曖昧	前提を明示し、判明している内容を分解して、不確かなタスクには「確認待ち」と記します。
機能が大きすぎる（20タスク以上）	複数の機能に分割します。数か月かかるものは機能ではなくプロジェクトです。
明確な受け入れ基準がない	「完了とはどのような状態ですか？　何をデモしますか？」と尋ね、ユーザーが基準を定義できるよう支援します。
技術スタックが不明	実装の詳細に踏み込まず、論理的なレベル（データモデル、ビジネスロジック、API、UI）で分解します。

分解しない場合

次の場合は、分解せずに進めることを提案します。

• タスクがすでにアトミックな場合（単一の関数、単一ファイルの変更）—そのまま実行します
• ユーザーがタスクの内訳ではなく所要時間の見積もりを求めている場合 — estimate-calibrator を使います
• 機能が探索的なもの（調査、プロトタイプ）の場合 — 分解には既知の範囲が必要です
• 目的地や定義に必要な判断がまだ不明な場合 — decision-map を使います