Eld Sense Task Decomposition

---
name: eld-sense-task-decomposition
description: |
  PCE (Process-Context Engine) のタスク分解スキル。親→子→孫の入れ子構造でタスクを分解し、各プロセスへのコンテキスト継承を設計する。

  トリガー条件:
  - 大きなタスクを受け取った時
  - 「このタスクを分解して」
  - 「実装計画を立てて」
  - 「作業を整理して」
  - 複雑な機能の実装開始時
---

# PCE Task Decomposition Skill

タスクを入れ子構造で分解し、各レベルでのコンテキスト継承を設計する。

## 分解の原則

1. **3段階まで**: 親→子→孫の3レベルを上限とする
2. **単一責務**: 各タスクは1つの責務に集中
3. **独立性**: 可能な限り並列実行可能に
4. **境界明確**: 責務の重複・漏れを防ぐ
5. **原子性**: 末端タスクは5-10分で完了する原子タスクに（Superpowers統合）

## 原子タスクの定義（Superpowers統合）

原子タスク = **5-10分で完了する最小単位のタスク**

### 原子性の基準

- [ ] 単一の概念変更（1つのシンボル/Law/Termに集中）
- [ ] 独立してテスト可能（他のタスクに依存しない）
- [ ] ロールバック可能（git checkout で戻せる）
- [ ] Evidence Ladder L0以上で検証可能
- [ ] 1タスク = 1コミット の原則

### 分解の粒度目安

| タスクサイズ | 時間目安 | 例 |
|------------|---------|-----|
| 原子タスク | 5-10分 | 型定義追加、1関数の実装、1テスト追加 |
| 子タスク | 20-40分 | モジュール実装、API層実装 |
| 親タスク | 2-4時間 | 機能全体の実装 |

詳細は `references/atomic-task-definition.md` を参照。

## Evidence付与ルール

各タスク（特に原子タスク）には以下を明示:

```yaml
task:
  name: <タスク名>
  level: L0 | L1 | L2 | L3 | L4  # Evidence Ladderレベル
  verification: <検証方法の具体的記述>
  law_term: [<関連Law ID>, <関連Term ID>]
  time_estimate: 5-10min        # 時間見積もり（原子タスクの場合）
```

### Law/Term紐付けの必須化

すべての原子タスクは、最低1つのLawまたはTermに紐付ける。
紐付けがない場合は、タスク分解が不適切と判断。

詳細は `references/evidence-requirement.md` を参照。

## 分解テンプレート

```markdown
# Task Decomposition: [親タスク名]

## Level 0: Root Task
**Goal**: [全体目標]
**Constraints**: [全体制約]
**Success Criteria**: [完了条件]

## Level 1: Major Components
### 1.1 [子タスク1]
- Goal: [目的]
- Boundary: [責務境界]
- Dependencies: [依存関係]
- Parallel: Yes/No
- Time Estimate: [時間見積もり]

### 1.2 [子タスク2]
...

## Level 2: Atomic Tasks（原子タスク）
### 1.1.1 [原子タスク1]
- Goal: [目的]
- Evidence Level: L0/L1/L2/L3/L4
- Verification: [検証方法]
- Law/Term: [LAW-xxx, TERM-yyy]
- Time Estimate: 5-10min
- Rollback Point: Yes

### 1.1.2 [原子タスク2]
...

## Context Inheritance Map
| From | To | Inherit | Return |
|------|-----|---------|--------|
| Root | 1.1 | [継承情報] | [戻す情報] |
| 1.1 | 1.1.1 | [Law/Term仕様] | [実装成果物] |

## Evidence Summary
| Task | Evidence Level | Law/Term | Verification |
|------|----------------|----------|--------------|
| 1.1.1 | L1 | LAW-xxx | ユニットテスト |
| 1.1.2 | L0 | TERM-yyy | 型チェック |
```

## 分解パターン

### パターン1: 機能分割
```
機能A実装
├── データ層
├── ビジネスロジック層
└── API層
```

### パターン2: フェーズ分割
```
機能A実装
├── 設計フェーズ
├── 実装フェーズ
└── テストフェーズ
```

### パターン3: ドメイン分割
```
Eコマース機能
├── 商品管理
├── カート管理
└── 決済処理
```

## 使用例

```
User: ユーザー認証システムを実装して

Claude:
# Task Decomposition: ユーザー認証システム

## Level 0: Root Task
**Goal**: JWT認証による安全なユーザー認証
**Constraints**: OWASP準拠、既存DBスキーマ活用
**Success Criteria**: ログイン/ログアウト/リフレッシュ動作

## Level 1: Major Components

### 1.1 認証コア
- Goal: JWTトークン生成・検証
- Boundary: トークン操作のみ、ユーザー管理は含まない
- Dependencies: なし
- Parallel: Yes
- Time Estimate: 30-40min

### 1.2 ユーザーセッション管理
- Goal: セッション状態の管理
- Boundary: セッションのみ、認証ロジックは含まない
- Dependencies: 1.1
- Parallel: No
- Time Estimate: 20-30min

### 1.3 API エンドポイント
- Goal: /auth/* のREST API
- Boundary: HTTPインターフェースのみ
- Dependencies: 1.1, 1.2
- Parallel: No
- Time Estimate: 30-40min

## Level 2: Atomic Tasks（1.1の原子タスク例）

### 1.1.1 JWTペイロード型定義
- Goal: JWTペイロードのTypeScript型定義
- Evidence Level: L0
- Verification: tsc型チェック通過
- Law/Term: TERM-jwt-payload (S1)
- Time Estimate: 5-7min
- Rollback Point: Yes

### 1.1.2 トークン生成関数実装
- Goal: JWT生成関数 generateToken() の実装
- Evidence Level: L1
- Verification: ユニットテスト（正常系+異常系）
- Law/Term: LAW-token-expiry (S0), LAW-token-signature (S0)
- Time Estimate: 8-10min
- Rollback Point: Yes

### 1.1.3 トークン検証関数実装
- Goal: JWT検証関数 verifyToken() の実装
- Evidence Level: L1
- Verification: ユニットテスト（期限切れ、改ざん検出）
- Law/Term: LAW-token-expiry (S0), LAW-token-signature (S0)
- Time Estimate: 8-10min
- Rollback Point: Yes

## Context Inheritance Map
| From | To | Inherit | Return |
|------|-----|---------|--------|
| Root | 1.1 | ADR-003, セキュリティ要件 | トークン仕様 |
| Root | 1.2 | セッション要件 | セッション設計 |
| 1.1 | 1.3 | トークン仕様 | API仕様 |
| 1.1 | 1.1.1 | JWTペイロード仕様 | 型定義ファイル |
| 1.1 | 1.1.2 | LAW-token-expiry, LAW-token-signature | generateToken実装 |
| 1.1 | 1.1.3 | LAW-token-expiry, LAW-token-signature | verifyToken実装 |

## Evidence Summary
| Task | Evidence Level | Law/Term | Verification |
|------|----------------|----------|--------------|
| 1.1.1 | L0 | TERM-jwt-payload | tsc型チェック |
| 1.1.2 | L1 | LAW-token-expiry, LAW-token-signature | ユニットテスト |
| 1.1.3 | L1 | LAW-token-expiry, LAW-token-signature | ユニットテスト |

分解完了。1.1.1から開始しますか？
```

---

## 品質優先原則（Superpowers統合）

### 核心原則

1. **Epistemic Humility**: 推測を事実として扱わない。`unknown`と言う勇気を持つ
2. **Evidence First**: 結論ではなく因果と証拠を中心にする
3. **Minimal Change**: 最小単位で変更し、即時検証する
4. **Grounded Laws**: Lawは検証可能・観測可能でなければならない
5. **Source of Truth**: 真実は常に現在のコード。要約はインデックス

### 「速さより質」の実践

- 要件の曖昧さによる手戻りを根本から排除
- テストなし実装を許さない
- 観測不能な変更を防ぐ

### 完了の定義

- [ ] Evidence Ladder目標レベル達成
- [ ] Issue Contractの物差し満足
- [ ] Law/Termが接地している（Grounding Map確認）
- [ ] Link Mapに孤立がない
- [ ] ロールバック可能な状態

### 停止条件

以下が発生したら即座に停止し、追加計測またはスコープ縮小：

- 予測と現実の継続的乖離（想定外テスト失敗3回以上）
- 観測不能な変更の増加（物差しで検証できない変更）
- ロールバック線の崩壊（戻せない変更の発生）