タスク分解スキル

タスクの複雑性を分析し、大きなタスクをDAGオーケストレーションスキルと互換性のある小さな並列化可能なサブタスクに分解します。オーケストレーターは実行前のプランニングフロントエンドとしてこれを使用します。

トリガー条件

以下のしきい値のいずれかを満たす場合、分解は推奨されます:

トリガー	しきい値	理由
推定期間	30分以上	単一エージェントには長すぎる
影響するファイル数	3ファイル以上	ファイル間で並列化可能
関連するドメイン数	2ドメイン以上	複数の専門家が必要
必要なエージェントタイプ数	2タイプ以上	複数分野間の調整が必要

ステップ0: パターン選択

分解する前に、適切なワークフローパターンを選択します:

パターン	使用時期	プリミティブ
Sequential（順序実行）	ステップが順序通りに実行される必要があり、各ステップが前のステップに依存	dag-orchestration (線形)
Parallel（並列実行）	共有状態のない独立したサブタスク	Agentツール (R009) またはAgent Teams (R018)
Evaluator-Optimizer（評価器-最適化器）	反復的な改善が必要な品質重視の出力	worker-reviewer-pipeline
Orchestrator（オーケストレーター）	動的ルーティングを伴う複雑なマルチステップ処理	ルーティングスキル (secretary/dev-lead/de-lead/qa-lead)

判定: タスクに独立したサブタスクがある場合 → Parallel。品質重視の場合 → EO レビューサイクルを追加。依存関係のあるマルチステップの場合 → Sequential/Orchestrator。

分解プロセス

1. タスクスコープを分析
   ├── 期間、ファイル数、ドメイン数を推定
   ├── 必要なエージェントタイプを特定
   └── トリガーしきい値を確認

2. しきい値を満たす場合 → 分解:
   ├── アトミックなサブタスクに分割 (単一エージェント、単一関心事)
   ├── サブタスク間の依存関係を特定
   ├── サブタスクをエージェントにマッピング (ルーティングスキルを使用)
   └── DAGワークフロー仕様を生成

2.5. pipeline-guardsの制限に対して粒度を検証:
     ├── 各サブタスクについて、推定ファイル数を計算
     ├── ファイル数 > 10 → アドバイザリーを発行: [Guard] ⚠ サブタスク "{id}" に {n} ファイルが割り当てられています (> 10) — レイヤーで分割
     ├── ファイル数 > 15 → ハード警告を発行: [Guard] 🛑 サブタスク "{id}" に {n} ファイルが割り当てられています (> 15) — 分割が必須
     └── すべてが ≤ 10 になるまで、大きすぎるサブタスクをレイヤー/ドメインで自動分割

3. プランをユーザーに提示 (R015 透明性)
   ├── 分解されたサブタスクとエージェントを表示
   ├── 依存関係グラフを表示
   ├── 推定並列実行時間を表示
   └── 実行前に確認をリクエスト

4. dag-orchestrationスキルで実行

分解ヒューリスティック

ファイル独立性による分解

Task: "5つのファイル間で認証モジュールを更新"
  ├── auth.ts → lang-typescript-expert
  ├── middleware.ts → lang-typescript-expert
  ├── config.ts → lang-typescript-expert (独立)
  ├── auth.test.ts → qa-engineer (依存: auth.ts)
  └── README.md → arch-documenter (依存: すべて)

DAG: [auth.ts, middleware.ts, config.ts] → auth.test.ts → README.md

ドメイン分離による分解

Task: "APIとUIを含むユーザープロフィール機能を追加"
  ├── APIエンドポイント → be-express-expert
  ├── データベーススキーマ → db-postgres-expert
  ├── フロントエンドコンポーネント → fe-vercel-agent
  └── 統合テスト → qa-engineer

DAG: [API, DB] → Frontend → 統合テスト
     (APIとDBは独立、Frontendは両方が必要)

レイヤーによる分解

Task: "Spring Bootで注文処理を実装"
  ├── ドメインモデル → lang-kotlin-expert
  ├── リポジトリ → be-springboot-expert (依存: ドメイン)
  ├── サービス → be-springboot-expert (依存: ドメイン、リポジトリ)
  ├── コントローラー → be-springboot-expert (依存: サービス)
  └── テスト → qa-engineer (依存: すべて)

DAG: ドメイン → [リポジトリ] → サービス → コントローラー → テスト

出力形式

分解プラン

[Task Decomposition]
├── 元のタスク: "JWTを使用したユーザー認証を追加"
├── 複雑性: 高 (4ファイル、3ドメイン、約45分)
├── 5つのサブタスクに分解:
│
│   [1] analyze (Explore:haiku)
│       既存の認証パターンをコードベースでスキャン
│
│   [2] implement-auth (lang-typescript-expert:sonnet)
│       JWT署名と検証を実装
│       依存: [1]
│
│   [3] implement-middleware (lang-typescript-expert:sonnet)
│       認証ミドルウェアを作成
│       依存: [1]
│
│   [4] write-tests (qa-engineer:sonnet)
│       認証テストを記述
│       依存: [2, 3]
│
│   [5] commit (mgr-gitnerd:sonnet)
│       すべての変更をコミット
│       依存: [4]
│
├── 並列レイヤー: 3 (レイヤー2で最大2つ同時実行)
├── 推定時間: 約20分 (順序実行の約45分に対して)
└── 進めますか? [Y/n]

生成されたDAG仕様

workflow:
  name: auto-decomposed-auth
  description: "自動分解: JWTを使用したユーザー認証を追加"

nodes:
  - id: analyze
    agent: Explore
    model: haiku
    prompt: "既存の認証パターンをコードベースでスキャン"
  - id: implement-auth
    agent: lang-typescript-expert
    model: sonnet
    prompt: "JWT署名と検証を実装"
    depends_on: [analyze]
  - id: implement-middleware
    agent: lang-typescript-expert
    model: sonnet
    prompt: "認証ミドルウェアを作成"
    depends_on: [analyze]
  - id: write-tests
    agent: qa-engineer
    model: sonnet
    prompt: "認証テストを記述"
    depends_on: [implement-auth, implement-middleware]
  - id: commit
    agent: mgr-gitnerd
    model: sonnet
    prompt: "すべての変更をコミット"
    depends_on: [write-tests]

config:
  max_parallel: 4
  failure_strategy: stop

アトミックタスク基準

サブタスクは以下の条件をすべて満たす場合にアトミックです:

• 単一のエージェントで処理可能
• 単一の関心事 (1つの論理的な変更)
• 独立してテスト可能な結果
• 推定期間が15分未満
• 影響するファイルが3ファイル以下 (理想的なアトミックサイズ)
• 10ファイルを超えてはならない (pipeline-guardsアドバイザリーしきい値)
• 10ファイルを超えることが不可避な場合 → [Guard]警告を発行し、レイヤー/ドメインで分割
• 15ファイルを超えることはハード違反 — 常にさらに分割 (pipeline-guardsハードキャップ)

サブタスクがアトミックでない場合 → さらに分解します (最大2レベル深い)。

粒度検証

分解後、各サブタスクをpipeline-guardsファイル制限に対して検証します:

サブタスクファイル数	アクション
3以下	理想的なアトミックサイズ — アクション不要
4-10	許容可能 — 警告なしで進行
11-15	アドバイザリー警告、さらなる分割を試みる
15超	ハード警告、実行前に分割が必須

検証プロセス

各分解されたサブタスクについて:

1. 推定ファイル数をカウント
2. 10を超える場合: a. 次を発行: [Guard] ⚠ サブタスク "{id}" に {n} ファイルが割り当てられています (> 10) — レイヤーで分割 b. 分割を試みる: レイヤー (ドメイン → アダプター → ハンドラー) またはドメイン分離 c. 分割結果を再検証
3. 分割試行後も15を超える場合: a. 次を発行: [Guard] 🛑 サブタスク "{id}" はまだ {n} ファイルを持っています (> 15) — ユーザーオーバーライドが必要 b. 進行前にユーザー確認を一時停止

生成されたDAGの調整

粒度検証が分割をトリガーする場合、DAG仕様を更新します:

• 元のノードが2つ以上の子ノードで置き換えられる
• 依存関係は保持される (子は親の依存関係を継承)
• configのmax_parallelはR009制限を尊重 (ソフト: 4、ハード: 5)

分解をスキップする場合

条件	理由
単一ファイルの編集	すでにアトミック
推定10分未満	オーバーヘッドの価値がない
ユーザーが明示的に「とにかくやれ」とリクエスト	ユーザーオーバーライド
単一ドメイン、単一エージェント	並列化のメリットなし

パーミッションモード

このスキルの実行中にAgentツール経由でエージェントをスポーンする場合、常にmode: "bypassPermissions"を渡します。Agentツールのデフォルト (acceptEdits) はエージェントフロントマターのpermissionModeをオーバーライドし、無人実行中にパーミッションプロンプトが発生します。

統合

コンポーネント	統合
dag-orchestration	dag-orchestrationによって消費されるDAG仕様を生成
ルーティングスキル	エージェント マッピングにdev-lead/de-lead/qa-leadルーティングを使用
R009	最大4制限内での並列化を最大化
R010	分解はオーケストレーターでのみ発生
R015	プランは実行前にユーザー承認のため表示される
R018	プランに3+エージェント → Agent Teams適格性をチェック
pipeline-guards	サブタスクファイル数を10/15粒度制限に対して検証