task-coordination-strategies

タスク調整戦略

複雑なタスクを並列化可能な単位に分解し、依存関係グラフを設計し、効果的なタスク記述を作成し、エージェントチーム全体のワークロードを監視するための戦略です。

このスキルを使用するタイミング

• 複雑なタスクを並列実行のために分解する場合
• タスクの依存関係（blockedBy/blocks）を設計する場合
• 明確な受け入れ基準を備えたタスク記述を作成する場合
• チームメイト全体のワークロードを監視し、再調整する場合
• 複数タスクのワークフローにおけるクリティカルパスを特定する場合

タスク分解戦略

レイヤー別

アーキテクチャのレイヤーごとに作業を分割します。

• フロントエンドコンポーネント
• バックエンド API エンドポイント
• データベースマイグレーション/モデル
• テストスイート

最適な用途: フルスタック機能、バーティカルスライス

コンポーネント別

機能コンポーネントごとに作業を分割します。

• 認証モジュール
• ユーザープロフィールモジュール
• 通知モジュール

最適な用途: マイクロサービス、モジュール式アーキテクチャ

関心事別

横断的な関心事ごとに作業を分割します。

• セキュリティレビュー
• パフォーマンスレビュー
• アーキテクチャレビュー

最適な用途: コードレビュー、監査

ファイルの所有権別

ファイル/ディレクトリの境界ごとに作業を分割します。

• src/components/ — 実装者 1
• src/api/ — 実装者 2
• src/utils/ — 実装者 3

最適な用途: 並列実装、競合の回避

依存関係グラフの設計

原則

1. チェーンの深さを最小化する — 深いチェーンよりも、広く浅いグラフを優先します
2. クリティカルパスを特定する — 最長のチェーンが最短完了時間を決定します
3. blockedBy は控えめに使用する — 真に必要な依存関係のみを追加します
4. 循環依存を避ける — タスク A が B をブロックし、B が A をブロックするのはデッドロックです

パターン

独立（最高の並列性）:

Task A ─┐
Task B ─┼─→ Integration
Task C ─┘

逐次（必要な依存関係）:

Task A → Task B → Task C

ダイヤモンド（混合）:

        ┌→ Task B ─┐
Task A ─┤          ├→ Task D
        └→ Task C ─┘

blockedBy/blocks の使用

TaskCreate: { subject: "Build API endpoints" }         → Task #1
TaskCreate: { subject: "Build frontend components" }    → Task #2
TaskCreate: { subject: "Integration testing" }          → Task #3
TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] }  → #3 waits for #1 and #2

タスク記述のベストプラクティス

すべてのタスクには以下を含める必要があります。

1. 目的 — 何を達成する必要があるか（1〜2 文）
2. 所有ファイル — このチームメイトが変更してよいファイル/ディレクトリの明示的なリスト
3. 要件 — 期待される具体的な成果物または動作
4. インターフェース契約 — この作業が他のチームメイトの作業とどのように接続するか
5. 受け入れ基準 — タスクが正しく完了したことを検証する方法
6. スコープの境界 — 明示的にスコープ外となるもの

テンプレート

## Objective
Build the user authentication API endpoints.

## Owned Files
- src/api/auth.ts
- src/api/middleware/auth-middleware.ts
- src/types/auth.ts (shared — read only, do not modify)

## Requirements
- POST /api/login — accepts email/password, returns JWT
- POST /api/register — creates new user, returns JWT
- GET /api/me — returns current user profile (requires auth)

## Interface Contract
- Import User type from src/types/auth.ts (owned by implementer-1)
- Export AuthResponse type for frontend consumption

## Acceptance Criteria
- All endpoints return proper HTTP status codes
- JWT tokens expire after 24 hours
- Passwords are hashed with bcrypt

## Out of Scope
- OAuth/social login
- Password reset flow
- Rate limiting

ワークロードの監視

不均衡の指標

シグナル	意味	対応
チームメイトがアイドル、他は多忙	配分の不均等	保留中のタスクを再割り当てする
チームメイトが 1 つのタスクで停滞	ブロッカーの可能性	状況を確認し、支援を申し出る
すべてのタスクがブロックされている	依存関係の問題	まずクリティカルパスを解決する
1 人のチームメイトが他より 3 倍多い	過負荷	タスクを分割または再割り当てする

再調整の手順

1. TaskList を呼び出して現在の状態を評価します
2. アイドル状態または過負荷のチームメイトを特定します
3. TaskUpdate を使用してタスクを再割り当てします
4. SendMessage を使用して影響を受けるチームメイトに通知します
5. スループットが改善されるか監視します