From 903111dd74e94d07c2ee63116e500a310c6df484 Mon Sep 17 00:00:00 2001 From: nrslib <38722970+nrslib@users.noreply.github.com> Date: Thu, 5 Mar 2026 23:16:32 +0900 Subject: [PATCH] =?UTF-8?q?feat:=20team=20leader=20=E3=81=AE=E5=88=86?= =?UTF-8?q?=E8=A7=A3=E5=93=81=E8=B3=AA=E3=82=92=E6=94=B9=E5=96=84=E3=81=99?= =?UTF-8?q?=E3=82=8B=E3=83=8A=E3=83=AC=E3=83=83=E3=82=B8=E3=81=A8=E3=82=A4?= =?UTF-8?q?=E3=83=B3=E3=82=B9=E3=83=88=E3=83=A9=E3=82=AF=E3=82=B7=E3=83=A7?= =?UTF-8?q?=E3=83=B3=E3=82=92=E8=BF=BD=E5=8A=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、 失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加 - team-leader-implement instruction: 分解前に可否を判断するステップを追加。 横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示 - takt-default-team-leader.yaml: implement movement に task-decomposition ナレッジを追加 --- .../instructions/team-leader-implement.md | 12 ++-- .../en/facets/knowledge/task-decomposition.md | 66 +++++++++++++++++++ .../en/pieces/takt-default-team-leader.yaml | 1 + .../instructions/team-leader-implement.md | 12 ++-- .../ja/facets/knowledge/task-decomposition.md | 66 +++++++++++++++++++ .../ja/pieces/takt-default-team-leader.yaml | 1 + 6 files changed, 148 insertions(+), 10 deletions(-) create mode 100644 builtins/en/facets/knowledge/task-decomposition.md create mode 100644 builtins/ja/facets/knowledge/task-decomposition.md diff --git a/builtins/en/facets/instructions/team-leader-implement.md b/builtins/en/facets/instructions/team-leader-implement.md index e598dc0..28e37fd 100644 --- a/builtins/en/facets/instructions/team-leader-implement.md +++ b/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: diff --git a/builtins/en/facets/knowledge/task-decomposition.md b/builtins/en/facets/knowledge/task-decomposition.md new file mode 100644 index 0000000..d4ef5d4 --- /dev/null +++ b/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 +``` diff --git a/builtins/en/pieces/takt-default-team-leader.yaml b/builtins/en/pieces/takt-default-team-leader.yaml index 293c3aa..a0ac386 100644 --- a/builtins/en/pieces/takt-default-team-leader.yaml +++ b/builtins/en/pieces/takt-default-team-leader.yaml @@ -124,6 +124,7 @@ movements: knowledge: - takt - architecture + - task-decomposition provider_options: claude: allowed_tools: diff --git a/builtins/ja/facets/instructions/team-leader-implement.md b/builtins/ja/facets/instructions/team-leader-implement.md index 80351c0..34acfd9 100644 --- a/builtins/ja/facets/instructions/team-leader-implement.md +++ b/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 に以下を必ず明記する： diff --git a/builtins/ja/facets/knowledge/task-decomposition.md b/builtins/ja/facets/knowledge/task-decomposition.md new file mode 100644 index 0000000..107af7c --- /dev/null +++ b/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 の生成から消費まで一貫して実装 +``` diff --git a/builtins/ja/pieces/takt-default-team-leader.yaml b/builtins/ja/pieces/takt-default-team-leader.yaml index 92ffbba..4bdba04 100644 --- a/builtins/ja/pieces/takt-default-team-leader.yaml +++ b/builtins/ja/pieces/takt-default-team-leader.yaml @@ -124,6 +124,7 @@ movements: knowledge: - takt - architecture + - task-decomposition provider_options: claude: allowed_tools: