Task Decompose

task-decompose: タスクのサブタスク分解

JIRAまたはGitHub Issueを受け取り、実装可能なサブタスクに分解する。各サブタスクは1コミット（1PR）程度の作業単位を目安とする。元タスクの仕様が分解に不十分な場合は、まず元タスクの更新を提案し、ユーザーの承認を得てから進める。

Step 1 — 入力の解析とタスク取得

$ARGUMENTS を解析してタスクのソースを特定する：

タスクの取得

JIRA: mcp__claude_ai_Atlassian__getJiraIssue を responseContentFormat: "markdown" で使用し、読みやすい形式でIssueの詳細を取得する。また mcp__claude_ai_Atlassian__getJiraProjectIssueTypesMetadata でプロジェクトのIssueタイプを取得し、利用可能なサブタスクタイプ名を確認する（プロジェクトによって「Subtask」「Sub-task」「サブタスク」等が異なる）。

GitHub: gh issue view <number> --repo <owner/repo> --json title,body,labels,assignees,milestone でIssueの詳細を取得する。

Step 2 — 仕様の十分性評価

タスクが分解可能かどうかは、具体的な実装ステップを決定できるだけの詳細があるかで判断する。以下の基準で仕様を評価する：

分解に必要な条件

• 目的: タスクが何を達成するかが明確に記述されている
• スコープ: スコープ内・スコープ外が特定可能である
• 受入基準: 完了をどのように検証するかが定義または推測可能である

仕様が不十分なサイン

• 説明が詳細のない一文のみ
• 重要な動作が曖昧（例：具体策なしに「エラーを適切に処理する」）
• 技術的アプローチに言及しているが説明がない
• 依存関係や前提条件に言及しているが不明確
• 複数の妥当な解釈が存在し、選択基準がない

仕様が十分な場合

Step 3 に進む。

仕様が不十分な場合

1. ギャップを特定する — 不足・曖昧な点を列挙する
2. 更新された説明文を起案する — ギャップを妥当な提案で埋める
3. ユーザーに更新内容を提示する：

## 仕様の不足点

以下の情報が不足または曖昧です：
- [ギャップ1]: [分解にとって重要な理由]
- [ギャップ2]: [分解にとって重要な理由]

## 提案する更新後の説明

[ギャップを埋めた完全な更新後の説明。追加部分を明示]

---
この内容でタスクを更新してよいですか？（適用前にテキストの編集も可能です）

4. ユーザーの承認を待つ。 確認が得られるまで進めない。
5. 更新を適用する：
   • JIRA: mcp__claude_ai_Atlassian__editJiraIssue を contentFormat: "markdown" で使用
   • GitHub: gh issue edit <number> --repo <owner/repo> --body <更新後の本文>

更新後、更新された仕様を使って Step 3 に進む。

Step 3 — サブタスクへの分解

タスクを各サブタスクが1コミット / 1PR 程度の作業量になるように分解する。これがデフォルトの粒度であり、ユーザーが引数や会話で別の粒度を指定した場合はそちらに従う。

分解の原則

• 逐次依存: サブタスクを順序付け、各タスクが前のタスクの上に構築されるようにする。タスクBがタスクAの出力に依存する場合、Aを先にする。
• 独立して検証可能: 各サブタスクは検証可能な結果を生成すべき — テストが通る、エンドポイントが応答する、UI要素が表示される、など。
• 原子的なスコープ: 1つのサブタスクに無関係な関心事を混在させない（例：些細な結合でない限り「DBマイグレーション追加」と「フロントエンドコンポーネント更新」を組み合わせない）。
• 明確な境界: 各サブタスクの説明から、作業の開始点と終了点が明確にわかるようにする。

各サブタスクに必要な情報

コードベースの調査

正確なサブタスクを作成するために、既存のコード構造を理解する必要がある場合がある。以下の場合にAgent tool（subagent_type: Explore）を使用してコードベースを調査する：

• タスクが既存のモジュール、API、コンポーネントを参照している場合
• 変更を計画するために現在のアーキテクチャを理解する必要がある場合
• ファイルパスやコンポーネント名を特定する必要がある場合

この調査により、曖昧な説明ではなく、具体的なファイル参照と現実的なスコープを持つサブタスクを作成できる。

Step 4 — サブタスク計画の提示

分解結果をユーザーレビューのために提示する：

# タスク分解: [元タスクのタイトル]

ソース: [URL]

## サブタスク（N件）

### 1. [サブタスクタイトル]
**スコープ**: [このサブタスクがカバーする範囲]
**主要ファイル**: [変更が予想されるファイル（特定可能な場合）]
**受入基準**:
- [基準1]
- [基準2]
**依存**: — （なし、または先行サブタスク番号を列挙）

### 2. [サブタスクタイトル]
**スコープ**: ...
**主要ファイル**: ...
**受入基準**: ...
**依存**: #1

...

---
これらのサブタスクを作成しますか？先に分解内容の調整を依頼することもできます。

ユーザーの承認を待つ。 ユーザーは以下を希望する可能性がある：

• サブタスクの統合または分割
• 順序の変更
• 項目の追加または削除
• 説明文の変更

すべてのフィードバックを反映してから進める。

Step 5 — サブタスクの作成

承認後、適切なプラットフォームでサブタスクを作成する。

JIRA

各サブタスクに mcp__claude_ai_Atlassian__createJiraIssue を使用する：

• cloudId: 元のIssueから抽出したサイトURL
• projectKey: 親Issueと同じプロジェクト
• issueTypeName: Step 1 で発見したサブタスクタイプ名（プロジェクトメタデータから）
• parent: 元のIssueキー（例：「PROJ-123」）
• summary: サブタスクタイトル
• description: 受入基準を含むサブタスクの完全な説明
• contentFormat: "markdown"

Issue番号が意図した順序を反映するよう、依存順にサブタスクを逐次作成する。

GitHub

各サブタスクに gh issue create を使用する：

gh issue create \
  --repo <owner/repo> \
  --title "[Parent#N] サブタスクタイトル" \
  --body "Parent: #N\nDepends on: #X\n\n<説明>"

全サブタスク作成後、親Issueに作成されたサブタスクを一覧するコメントを追加する：

gh issue comment <parent-number> --repo <owner/repo> \
  --body "## サブタスク\n- [ ] #A サブタスク1\n- [ ] #B サブタスク2\n..."

これにより、親Issueに進捗追跡用のチェックリストが作成される。

Step 6 — サマリー

作成結果を報告する：

# 分解完了

**ソース**: [元タスクのURL]
**作成されたサブタスク数**: N

| # | キー/番号 | タイトル | 依存 |
|---|-----------|-------|------------|
| 1 | PROJ-124 / #45 | ユーザーバリデーションミドルウェアの追加 | — |
| 2 | PROJ-125 / #46 | 認証エンドポイントの実装 | #1 |
| 3 | PROJ-126 / #47 | 結合テストの追加 | #2 |

Tips

• 8〜10個以上のサブタスクに分解される大きなタスクの場合、タスク＋サブタスクではなくエピック＋ストーリーにすべきかを検討する。該当する場合はユーザーに言及する。
• コードベースがローカルにある場合、調査により具体的なファイルパスやコンポーネント名を含むより良いサブタスク説明を作成できる。
• JIRAサブタスク作成時、parentフィールドで親Issueに直接リンクされる。GitHubの場合、親子関係はIssue本文の参照とチェックリストコメントで維持される。