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

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

2026-03-05 23:16:32 +09:00

2.7 KiB

Raw Blame History

タスク分解知識

分解の可否判断

タスクを複数パートに分解する前に、分解が適切かを判断する。分解が不適切なケースでは1パートで実装する方が効率的。

基準	判定
変更ファイルが明確にレイヤー分離できる	分解可
共有する型・IDが複数パートをまたぐ	1パートで実装
広範囲のリネーム・リファクタ	1パートで実装
変更ファイル数が5未満	1パートで実装
同一ファイルを複数パートが触る必要がある	1パートで実装

横断的関心事の検出

以下に該当する場合、独立パートでは整合性を保てない。1パートにまとめる。

新しいID・キー・型を生成し、別のモジュールで消費するフロー
イベント発火側と受信側の両方を変更する
既存インターフェースのシグネチャを変更し、全呼び出し元を更新する

ファイル排他の原則

複数パートに分解する場合、各パートの担当ファイルは完全に排他的でなければならない。

基準	判定
同一ファイルを複数パートが編集	REJECT（コンフリクトの原因）
型定義と利用側が別パート	型定義側のパートにまとめる
テストファイルと実装ファイルが別パート	同じパートにまとめる

グループ化の優先順位

依存方向で分ける — 依存元と依存先は同じパートに
レイヤーで分ける — ドメイン層 / インフラ層 / API層
機能で分ける — 独立した機能単位

失敗パターン

パート重複

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 の生成から消費まで一貫して実装

2.7 KiB Raw Blame History Unescape Escape