# SpawnSubTask

タスクを並列サブタスクに分解して実行する。各サブタスクは独立した worker（ジョブ）で動き、完了後に親タスクが結果を集約する。

## 基本

```js
SpawnSubTask({
  title: "ローカル LLM 比較調査",
  instruction: "Ollama, vLLM, llama.cpp の最新性能ベンチマークを比較する。各ツールについて: 1) 直近6ヶ月の主要ベンチマーク, 2) ハードウェア要件, 3) 対応モデル一覧 を output/report.md にまとめる。",
  piece: "research"   // 任意。指定しないと自動分類
})
```

呼び出すと `subtasks/{index}/` にサブタスクのワークスペースが作られ、結果はそこに集約される。

## いつ使うか

### 並列分解が効果的なケース

- 2 つ以上の **独立したテーマ**（互いに参照しない）
- 各テーマが軽くなく、調査・処理に時間がかかる
- 分解後の各タスクが単独でも意味を持つ成果物になる

例:
- 「3 つの製品比較レポート」→ 製品ごとに 3 サブタスク
- 「複数 PDF の OCR 処理」→ ファイルごとに分解
- 「複数 SNS の情報収集」→ プラットフォーム別に分解

### 分解しないほうがよいケース

- 単一テーマで論理的に連続する処理（A→B→C のように依存）
- サブタスクが極端に小さい（オーバーヘッドの方が大きい）
- 全体像を見ながら判断する必要がある作業（対話的タスク等）

## instruction の書き方

- **完結した依頼文**で書く（親タスクの文脈を持たないので、サブタスクは instruction だけで判断する）
- 期待する成果物（出力ファイル名・場所）を明示
- 必要な前提情報があれば文中に展開

❌ 「これと同じ調査を別キーワードでやって」
✅ 「キーワード『A』『B』『C』について、各々のメリット・デメリットを比較する独立した調査を行い、output/A-vs-B.md にまとめる」

## piece の指定

- 省略時: 親と同じ classifier ロジックで自動選択
- 明示する場合: `research`, `general`, `office-process` 等の piece 名を指定

## 結果の参照

サブタスク完了後、親タスクは:
- `subtasks/{index}/output/` 以下にサブタスクの成果物がある
- Read で参照して集約レポートを作成する

## 制限

- ネスト深さは `subtasks.maxDepth`（デフォルト 2）まで
- サブタスクが waiting_human 等で停止すると親もブロックされる