name: eld-sense-task-decomposition description: | PCE (Process-Context Engine) のタスク分解スキル。親→子→孫の入れ子構造でタスクを分解し、各プロセスへのコンテキスト継承を設計する。
トリガー条件:
- 大きなタスクを受け取った時
- 「このタスクを分解して」
- 「実装計画を立てて」
- 「作業を整理して」
- 複雑な機能の実装開始時
PCE Task Decomposition Skill
タスクを入れ子構造で分解し、各レベルでのコンテキスト継承を設計する。
分解の原則
- 3段階まで: 親→子→孫の3レベルを上限とする
- 単一責務: 各タスクは1つの責務に集中
- 独立性: 可能な限り並列実行可能に
- 境界明確: 責務の重複・漏れを防ぐ
- 原子性: 末端タスクは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付与ルール
各タスク（特に原子タスク）には以下を明示:
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 を参照。
分解テンプレート
# 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統合）
核心原則
- Epistemic Humility: 推測を事実として扱わない。
unknownと言う勇気を持つ - Evidence First: 結論ではなく因果と証拠を中心にする
- Minimal Change: 最小単位で変更し、即時検証する
- Grounded Laws: Lawは検証可能・観測可能でなければならない
- Source of Truth: 真実は常に現在のコード。要約はインデックス
「速さより質」の実践
- 要件の曖昧さによる手戻りを根本から排除
- テストなし実装を許さない
- 観測不能な変更を防ぐ
完了の定義
- Evidence Ladder目標レベル達成
- Issue Contractの物差し満足
- Law/Termが接地している（Grounding Map確認）
- Link Mapに孤立がない
- ロールバック可能な状態
停止条件
以下が発生したら即座に停止し、追加計測またはスコープ縮小：
- 予測と現実の継続的乖離（想定外テスト失敗3回以上）
- 観測不能な変更の増加（物差しで検証できない変更）
- ロールバック線の崩壊（戻せない変更の発生）