適切なサイズ:
  - 1つの機能 = 1つのタスク
  - 1つのテストファイル = 1つのタスク
  - 1つの API エンドポイント = 1つのタスク

分解が必要なサイン:
  - 「〜と〜」という接続詞が含まれる
  - 受け入れ条件が5個以上
  - 複数のファイルにまたがる変更

明示的依存（explicit）:
  - 定義: 直接的な参照関係
  - 例: "認証機能"が"ログイン画面"に必要

暗黙的依存（implicit）:
  - 定義: データフローや処理順序による依存
  - 例: "DB設計"が"データ取得API"に先行

ブロッキング依存（blocking）:
  - 定義: 完了しないと次が開始できない
  - 例: "スキーマ定義"が"マイグレーション"をブロック

# 既存の Issue を確認
gh issue list --json number,title,state,labels

# project.md を確認
cat src/{library_name}/docs/project.md

### タスク: [タスク名]
- 概要: [何をするか]
- 受け入れ条件:
  - [ ] [条件1]
  - [ ] [条件2]
- 依存: [先行タスク]
- 見積もり: [時間]

高類似度（70%以上）:
  - 同じ機能領域
  - 同じコンポーネント
  - 対応: 既存 Issue の sub-issue として追加

中類似度（40-70%）:
  - 関連する機能領域
  - 一部共通するキーワード
  - 対応: ユーザーに確認

低類似度（40%未満）:
  - 異なる機能領域
  - 対応: 新規 Issue として作成

graph TD
    A[タスク1: 認証基盤] --> B[タスク2: ログイン画面]
    A --> C[タスク3: ログアウト処理]
    B --> D[タスク4: セッション管理]
    C --> D

# Issue 一覧取得
gh issue list --json number,title,body,labels,state

# Issue 作成
gh issue create \
  --title "[日本語タイトル]" \
  --body "[日本語本文]" \
  --label "enhancement"

# Issue 更新
gh issue edit [番号] --body "[更新本文]"

# Issue クローズ
gh issue close [番号]

# Project Item 一覧
gh project item-list {project_number} --owner @me --format json

# Project に Issue を追加
gh project item-add {project_number} --owner @me --url {issue_url}

# ステータス更新
gh project item-edit \
  --project-id {project_id} \
  --id {item_id} \
  --field-id {status_field_id} \
  --single-select-option-id {status_option_id}

## タスク分解結果

### 1. 認証基盤の実装
- Issue: [#100](URL)
- 依存: なし
- 受け入れ条件:
  - [ ] JWT トークン生成
  - [ ] トークン検証

### 2. ログイン画面の実装
- Issue: [#101](URL)
- 依存: #100
- 受け入れ条件:
  - [ ] フォーム実装
  - [ ] バリデーション

## 依存関係グラフ

```mermaid
graph TD
    A[#100 認証基盤] --> B[#101 ログイン画面]
    B --> C[#102 セッション管理]

---

### 例2: 既存タスクとの類似性判定

**状況**: 「APIエラーハンドリングを追加」という新規タスク

**処理**:
1. 既存 Issue を検索
2. 類似度を計算（タイトル、本文、ラベル）
3. 類似 Issue を提示
4. ユーザーに確認

**期待される出力**:
```yaml
類似性判定結果:
  新規タスク: "APIエラーハンドリングを追加"

  類似 Issue:
    - number: 50
      title: "エラーレスポンスの統一"
      similarity: 75%
      recommendation: "sub-issue として追加を推奨"

    - number: 32
      title: "バリデーションエラーの処理"
      similarity: 45%
      recommendation: "関連として紐付けを検討"

推奨アクション: #50 の sub-issue として作成

⚠️ 循環依存を検出しました

循環パス:
  タスクA (認証) → タスクB (API) → タスクC (セッション) → タスクA (認証)

原因分析:
  - セッション管理が認証に依存
  - 認証がセッション状態を参照

解消案:
  1. インターフェース分離: 共通インターフェースを抽出
  2. 依存逆転: セッション → 認証の依存を逆転
  3. 共有コンポーネント: 共通部分を別タスクに分離

推奨: 案3「共有コンポーネント」- 認証コアを独立タスクとして分離

## 並行開発グループ（Wave 分析）

### Wave 1（並行開発可能）
- #100: DB スキーマ定義
- #101: UI コンポーネント基盤

### Wave 2（Wave 1 完了後）
- #102: データ取得 API（依存: #100）
- #103: フォームコンポーネント（依存: #101）

### Wave 3（Wave 2 完了後）
- #104: 統合テスト（依存: #102, #103）

```mermaid
graph LR
    subgraph Wave1
        A[#100 DB]
        B[#101 UI]
    end
    subgraph Wave2
        C[#102 API]
        D[#103 Form]
    end
    subgraph Wave3
        E[#104 統合]
    end
    A --> C
    B --> D
    C --> E
    D --> E

## 品質基準

### 必須（MUST）

- [ ] 全タスクに明確な受け入れ条件がある
- [ ] 依存関係が明示されている
- [ ] 循環依存がない
- [ ] タスクが1-2時間で完了可能なサイズ

### 推奨（SHOULD）

- 各タスクが独立してテスト可能
- Mermaid での可視化が含まれている
- 既存 Issue との類似性チェックが実施されている
- 見積もり時間が記載されている

## 出力フォーマット

### タスク分解完了時

### 類似性判定時

```yaml
判定結果:
  対象タスク: "{task_title}"
  類似 Issue:
    - number: {issue_number}
      similarity: {percentage}%
      recommendation: "{action}"

判定: {new_issue | sub_issue | confirm_with_user}