PCE Task Decomposition Skill

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コミット の原則

分解の粒度目安

詳細は 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統合）

核心原則

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回以上）
• 観測不能な変更の増加（物差しで検証できない変更）
• ロールバック線の崩壊（戻せない変更の発生）