Issue分解コマンド (/decompose-issue)

既存の大きなIssueを適切な粒度のSubtask（子Issue）に分解します。 200行以下・3ファイル以下の粒度で子Issueを作成し、並列実装を可能にします。

処理フロー

1. 親Issue解析
   ↓
2. 依存関係グラフ作成
   ↓
3. 分解計画の作成（Phase 3.5 承認ゲート）
   ↓
4. 子Issue作成（GitHub API）
   ↓
5. 親Issue更新（タスクリスト追加）

1. 粒度判定（分解が必要か？）

参照元:

issue-size-estimation

skill

/decompose-issue

目安となるキーワード

• "Implement entire feature..."
• "Create CRUD for..."
• "Add authentication system..."

2. 分解戦略（Decomposition Strategy）

2.1 水平分割（レイヤー別）

機能全体をレイヤーごとに分割する（最も一般的）。

• Subtask 1: DB Schema & Model
• Subtask 2: API/Backend Logic
• Subtask 3: Frontend UI

2.2 垂直分割（機能別）

独立した機能ごとに分割する。

• Subtask 1: Login API
• Subtask 2: Register API
• Subtask 3: Forgot Password API

2.3 依存関係の考慮

• Is blocking

  : 先に実装する必要があるIssue

• Blocked by

  : 依存先のIssueが完了するまで着手できないIssue

3. 出力形式

Phase 3.5: 分解計画承認（Approval Gate）

Subtask作成前に、ユーザーに分解計画を提示して承認を得る。

## 🧩 Issue分解計画承認

### 親Issue
#123: ユーザー認証機能の実装

### 提案するSubtask構成

| ID | Subtask名 | 依存関係 | 推定行数 |
|----|-----------|---------|---------|
| **S1** | DBスキーマとマイグレーション | - | 50行 |
| **S2** | バックエンドAPI実装 | Blocked by S1 | 150行 |
| **S3** | フロントエンドログイン画面 | Blocked by S2 | 100行 |

### 合計
- Subtask数: 3
- 総推定行数: 300行

---
**この計画でSubtaskを作成しますか？**

1. 作成する → GitHub Issueを作成
2. 修正する → 構成を見直す
3. キャンセル

4. Subtask作成後のアクション

Subtask作成後、Sisyphusに次のアクションを提示する。

✅ Subtaskを作成しました。

### 作成されたIssue
- #124: DBスキーマとマイグレーション
- #125: バックエンドAPI実装
- #126: フロントエンドログイン画面

### 次のステップ
1. 実装に進む（順次実装）

コマンド使用方法

/decompose-issue <issue_id>

例:

/decompose-issue 123

エラーハンドリング

関連スキル

• issue-size-estimation

  : 粒度判定ロジック

• github-issue-dependency

  : 依存関係設定

• approval-gate

  : 承認ゲートフォーマット