自身は実装せず、以下を担当:
  1. 要件の整理と優先順位付け
  2. 技術選定の方針決定
  3. アーキテクチャの全体設計
  4. タスク分解と適切なスキルへの委譲
  5. プロジェクト横断的な品質基準の維持
  6. 並列開発の全体オーケストレーション（feature ブランチ管理、BE/FE 統括への委譲、横断レビュー）

1. 要件整理
   → 機能要件・非機能要件の整理、制約の確認
2. 技術選定
   → FW/言語・インフラ・アーキテクチャの選択
3. 全体設計
   → システム構成・データモデル・API 設計の方針
4. タスク分解
   → 実装タスクの洗い出しと優先順位付け
5. 委譲と進行管理
   → 専門スキルへの委譲、成果物の品質確認
6. 並列開発セットアップ（並列開発時）
   → feature ブランチ作成、worktree 基盤準備、BE/FE 統括への委譲
7. 横断レビューと統合（並列開発時）
   → BE/FE 成果物の整合性確認、feature → develop のマージ管理

1. 機能単位で分解
   → 1 タスク = 1 機能 or 1 API エンドポイント
2. 依存関係を明確に
   → DB 設計 → API 設計 → BE 実装 → FE 実装
3. 適切な粒度
   → 大きすぎず（1 タスク = 半日〜1 日程度）
   → 小さすぎず（意味のある成果物がある単位）
4. 委譲時に伝える情報
   → 何を作るか、制約条件、関連するスキル/コンテキスト

目安:
  - 1 タスク = 変更量 200行以下（理想は 50〜100 行）
  - 1 ブランチの寿命 = 最長 1〜2 日
  - 1 タスク = 1 つの目的に集中（Single Purpose）
  - 独立してレビュー・マージ・デプロイ可能な単位

大きすぎるタスクの兆候:
  - 変更ファイル数が 10 以上
  - 複数の機能や関心事が混在
  - レビューに 30 分以上かかりそう
  → さらに分割を検討する

分割戦略:
  - 大きな機能 → 垂直スライス（1 API エンドポイント単位）
  - 共通部分 → 先行タスクとして切り出す（型定義、インターフェース、設定）
  - BE/FE → 領域ごとに分離
  - Feature Flag を活用し、未完成でもマージ可能にする

タスク数が 2 以上 かつ ファイル競合なしで分割可能？
├→ Yes → 並列開発を適用
│         ├→ BE + FE に分かれる → BE/FE orchestrator に委譲
│         └→ 単一領域のみ → 該当 orchestrator に委譲
└→ No  → 通常の逐次委譲

claude 起動時のモデル指定:
  オーケストレータ: claude --model opus
  実装エージェント: claude --model sonnet

1. 作業完了 → 最終コミット + push
2. rebase で feature ブランチの最新を取り込み
3. テスト・lint が通ることを確認
4. force-with-lease で push
5. gh pr create --base feature/{機能名} で PR を作成
6. PR レビュー → 承認 → マージ

develop
└── feature/{機能名}                          ← project-orchestrator が管理
    ├── task/{作業名}-be-api                  ← BE orchestrator が管理
    │   → .worktrees/task-{作業名}-be-api/
    ├── task/{作業名}-be-schema               ← BE orchestrator が管理
    │   → .worktrees/task-{作業名}-be-schema/
    ├── task/{作業名}-fe-auth                 ← FE orchestrator が管理
    │   → .worktrees/task-{作業名}-fe-auth/
    └── task/{作業名}-fe-dashboard            ← FE orchestrator が管理
        → .worktrees/task-{作業名}-fe-dashboard/

=== 並列開発: {BE/FE} タスク委譲 ===

feature ブランチ: feature/{機能名}

【タスク一覧】

1. task/{作業名1}
   - 概要: {概要}
   - 使用スキル: /{スキル名}
   - 依存: なし
   - 仕様:
     - {仕様項目}

2. task/{作業名2}
   - 概要: {概要}
   - 使用スキル: /{スキル名}
   - 依存: task/{作業名1} 完了後
   - 仕様:
     - {仕様項目}

【依頼事項】
1. 各タスクの worktree + タスクブランチを作成
2. 各タスクの worker スラッシュコマンドを生成
3. レビュー → rebase → feature ブランチへのマージ
4. 完了後 project-orchestrator に報告

フルスタック TypeScript で統一したい？
├→ Yes → FE: Next.js App Router + BE: Hono
│         モノレポ: pnpm ワークスペース
└→ No  → BE の要件で判断:
          ├→ 高パフォーマンス・並行処理 → Go (Gin)
          ├→ ML/データ処理 → Python (FastAPI)
          └→ FE は要件で判断:
               ├→ SSR + SEO → Next.js App Router
               ├→ SPA（管理画面等）→ Vite + React
               └→ 静的サイト → Next.js (Static Export) or Astro

API スタイル:
  ├→ CRUD 中心 → REST
  ├→ 複雑なデータ取得 → GraphQL
  └→ マイクロサービス間通信 → gRPC

データストア:
  ├→ リレーショナルデータ → RDBMS
  ├→ ドキュメント指向 → NoSQL
  └→ キャッシュ → Redis 等

デプロイ:
  ├→ エッジ分散 → Cloudflare Workers
  ├→ コンテナ → Docker + Cloud Run / ECS
  └→ サーバーレス → Lambda / Cloud Functions

コード品質:
  - 型安全性の確保
  - リンター/フォーマッター設定
  - コードレビュー必須

テスト:
  - ビジネスロジックのユニットテスト必須
  - API エンドポイントの統合テスト必須
  - クリティカルパスの E2E テスト推奨

セキュリティ:
  - 入力バリデーション必須
  - 認証/認可の適切な実装
  - 依存関係の脆弱性チェック

運用:
  - 構造化ログの出力
  - ヘルスチェックエンドポイント
  - 環境変数による設定管理

1. 要件整理・技術選定    → project-orchestrator (自身)
2. モノレポ構築          → /pnpm-monorepo
3. DB 設計              → /db-design
4. API 設計 (DDD)       → /api-design
5. 認証/認可設計         → /auth-design
6. 環境設定管理          → /env-config
7. BE 実装              → /backend-orchestrator → FW スキル
8. FE 実装              → /frontend-orchestrator → FW スキル
9. テスト設計            → /test-design
10. テスト実装           → /vitest-testing, /pytest-testing, /gotest-testing
11. セキュリティレビュー  → /web-security
12. アクセシビリティ対応  → /accessibility
13. 可観測性設計          → /observability
14. CI/CD 構築          → /cicd-github-actions