feat: team leader の分解品質を改善するナレッジとインストラクションを追加

- knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、
  失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加
- team-leader-implement instruction: 分解前に可否を判断するステップを追加。
  横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示
- takt-default-team-leader.yaml: implement movement に task-decomposition
  ナレッジを追加

builtins/en/facets/instructions/team-leader-implement.md

@@ -1,17 +1,19 @@
-Decompose the implementation task into subtasks by file ownership and execute them in parallel. Assign files exclusively to each part to prevent conflicts.
+Analyze the implementation task and, if decomposition is appropriate, split into multiple parts for parallel execution.
 
 **Important:** Reference the plan report: {report:plan.md}
 
 **Steps:**
 
-1. Identify files to create/modify
-   - Reference the plan report and test scope to list all files to change
-   - Review the actual codebase to fill in any missing information
+1. Assess whether decomposition is appropriate
+   - Identify files to change and check inter-file dependencies
+   - If cross-cutting concerns exist (shared types, IDs, events), implement in a single part
+   - If few files are involved, or the task is a rename/refactoring, implement in a single part
 
-2. Group files by layer/module
+2. If decomposing: group files by layer/module
    - Create groups based on high cohesion (e.g., Domain layer / Infrastructure layer / API layer)
    - If there are type or interface dependencies, keep both sides in the same group
    - Never assign the same file to multiple parts
+   - Keep test files and implementation files in the same part
 
 3. Assign file ownership exclusively to each part
    - Each part's instruction must clearly state:

builtins/en/facets/knowledge/task-decomposition.md

@@ -0,0 +1,66 @@
+# Task Decomposition Knowledge
+
+## Decomposition Feasibility
+
+Before splitting a task into multiple parts, assess whether decomposition is appropriate. When decomposition is unsuitable, implementing in a single part is more efficient.
+
+| Criteria | Judgment |
+|----------|----------|
+| Changed files clearly separate into layers | Decompose |
+| Shared types/IDs span multiple parts | Single part |
+| Broad rename/refactoring | Single part |
+| Fewer than 5 files to change | Single part |
+| Same file needs editing by multiple parts | Single part |
+
+### Detecting Cross-Cutting Concerns
+
+When any of the following apply, independent parts cannot maintain consistency. Consolidate into a single part.
+
+- A new ID, key, or type is generated in one module and consumed in another
+- Both the event emitter and event receiver need changes
+- An existing interface signature changes, requiring updates to all call sites
+
+## File Exclusivity Principle
+
+When decomposing into multiple parts, each part's file ownership must be completely exclusive.
+
+| Criteria | Judgment |
+|----------|----------|
+| Same file edited by multiple parts | REJECT (causes conflicts) |
+| Type definition and consumer in different parts | Consolidate into the type definition part |
+| Test file and implementation file in different parts | Consolidate into the same part |
+
+### Grouping Priority
+
+1. **By dependency direction** — keep dependency source and target in the same part
+2. **By layer** — domain layer / infrastructure layer / API layer
+3. **By feature** — independent functional units
+
+## Failure Patterns
+
+### Part Overlap
+
+When two parts own the same file or feature, sub-agents overwrite each other's changes, causing repeated REJECT in reviews.
+
+```
+// NG: part-2 and part-3 own the same file
+part-2: taskInstructionActions.ts — instruct confirmation dialog
+part-3: taskInstructionActions.ts — requeue confirmation dialog
+
+// OK: consolidate into one part
+part-1: taskInstructionActions.ts — both instruct/requeue confirmation dialogs
+```
+
+### Shared Contract Mismatch
+
+When part A generates an ID that part B consumes, both parts implement independently, leading to mismatches in ID name, type, or passing mechanism.
+
+```
+// NG: shared contract across independent parts
+part-1: generates phaseExecutionId
+part-2: consumes phaseExecutionId
+→ part-1 uses string, part-2 expects number → integration error
+
+// OK: single part for consistent implementation
+part-1: implements phaseExecutionId from generation to consumption
+```

builtins/en/pieces/takt-default-team-leader.yaml

@@ -124,6 +124,7 @@ movements:
     knowledge:
       - takt
       - architecture
+      - task-decomposition
     provider_options:
       claude:
         allowed_tools:

builtins/ja/facets/instructions/team-leader-implement.md

@@ -1,17 +1,19 @@
-実装タスクをファイル担当単位でサブタスクに分解し、並列実行してください。各パートが担当するファイルが重複しないよう排他的に割り当てます。
+実装タスクを分析し、分解が適切なら複数パートに分けて並列実行してください。
 
 **重要:** 計画レポートを参照してください: {report:plan.md}
 
 **やること:**
 
-1. 変更対象ファイルを特定する
-   - 計画レポートとテストスコープを参照して変更・作成するファイルを洗い出す
-   - 実際のコードベースを確認して不明点を補完する
+1. 分解の可否を判断する
+   - 変更対象ファイルを特定し、ファイル間の依存関係を確認する
+   - 横断的関心事（共有型・ID・イベント）がある場合は分解せず1パートで実装する
+   - 変更ファイル数が少ない場合、リファクタ・リネーム系の場合も1パートで実装する
 
-2. ファイルをレイヤー/モジュール単位でグループ化する
+2. 分解する場合: ファイルをレイヤー/モジュール単位でグループ化する
    - 凝集度の高い単位でグループを作る（例: ドメイン層 / インフラ層 / API層）
    - 型・インターフェースの依存がある場合は、依存元と依存先を同じグループにまとめる
    - 1つのファイルを複数のパートに割り当てない
+   - テストファイルと実装ファイルは同じパートにまとめる
 
 3. 各パートに排他的なファイル担当を割り当てる
    - 各パートの instruction に以下を必ず明記する：

builtins/ja/facets/knowledge/task-decomposition.md

@@ -0,0 +1,66 @@
+# タスク分解知識
+
+## 分解の可否判断
+
+タスクを複数パートに分解する前に、分解が適切かを判断する。分解が不適切なケースでは1パートで実装する方が効率的。
+
+| 基準 | 判定 |
+|------|------|
+| 変更ファイルが明確にレイヤー分離できる | 分解可 |
+| 共有する型・IDが複数パートをまたぐ | 1パートで実装 |
+| 広範囲のリネーム・リファクタ | 1パートで実装 |
+| 変更ファイル数が5未満 | 1パートで実装 |
+| 同一ファイルを複数パートが触る必要がある | 1パートで実装 |
+
+### 横断的関心事の検出
+
+以下に該当する場合、独立パートでは整合性を保てない。1パートにまとめる。
+
+- 新しいID・キー・型を生成し、別のモジュールで消費するフロー
+- イベント発火側と受信側の両方を変更する
+- 既存インターフェースのシグネチャを変更し、全呼び出し元を更新する
+
+## ファイル排他の原則
+
+複数パートに分解する場合、各パートの担当ファイルは完全に排他的でなければならない。
+
+| 基準 | 判定 |
+|------|------|
+| 同一ファイルを複数パートが編集 | REJECT（コンフリクトの原因） |
+| 型定義と利用側が別パート | 型定義側のパートにまとめる |
+| テストファイルと実装ファイルが別パート | 同じパートにまとめる |
+
+### グループ化の優先順位
+
+1. **依存方向で分ける** — 依存元と依存先は同じパートに
+2. **レイヤーで分ける** — ドメイン層 / インフラ層 / API層
+3. **機能で分ける** — 独立した機能単位
+
+## 失敗パターン
+
+### パート重複
+
+2つのパートが同じファイルや同じ機能を担当すると、サブエージェントが互いの変更を上書きし、レビューで繰り返しREJECTされる。
+
+```
+// NG: part-2 と part-3 が同じファイルを担当
+part-2: taskInstructionActions.ts — instruct機能の確認ダイアログ
+part-3: taskInstructionActions.ts — requeue機能の確認ダイアログ
+
+// OK: 1パートにまとめる
+part-1: taskInstructionActions.ts — instruct/requeue両方の確認ダイアログ
+```
+
+### 共有契約の不整合
+
+パートAが生成するIDをパートBが消費する設計では、両パートが独立に実装するため、ID名・型・受け渡し方法に不整合が生じる。
+
+```
+// NG: 独立パートで共有契約
+part-1: phaseExecutionId を生成
+part-2: phaseExecutionId を受け取って使う
+→ part-1 は string、part-2 は number を期待 → 統合エラー
+
+// OK: 1パートで一貫実装
+part-1: phaseExecutionId の生成から消費まで一貫して実装
+```

builtins/ja/pieces/takt-default-team-leader.yaml

@@ -124,6 +124,7 @@ movements:
     knowledge:
       - takt
       - architecture
+      - task-decomposition
     provider_options:
       claude:
         allowed_tools: