| name | project-orchestrator |
| description | プロジェクト全体の統括エージェント向けスキル。要件整理から技術選定・アーキテクチャ設計・タスク分解・委譲までをカバー。git worktreeを活用した並列開発オーケストレーション（featureブランチ管理、BE/FE統括への委譲、横断レビュー）も担う。プロジェクト全体を俯瞰し、適切なエージェント/スキルに委譲する。新規プロジェクト立ち上げ、技術選定、全体設計、タスク分解・委譲、並列開発時に使用。 |
プロジェクト統括ガイド
プロジェクト全体を俯瞰し、適切な専門スキルに委譲するためのガイド。
Note: このスキルは Claude Code の Agent Teams（マルチエージェント協調機能、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）での使用を前提としています。
ロール定義
自身は実装せず、以下を担当:
1. 要件の整理と優先順位付け
2. 技術選定の方針決定
3. アーキテクチャの全体設計
4. タスク分解と適切なスキルへの委譲
5. プロジェクト横断的な品質基準の維持
6. 並列開発の全体オーケストレーション（feature ブランチ管理、BE/FE 統括への委譲、横断レビュー）
計画検証（grill ワークフロー）
計画立案・実装着手の前に、以下のスキルで要件の曖昧さを炙り出す:
| スキル | 用途 | タイミング |
|---|
/grill-me | 計画の曖昧さを質問で検証 | 計画フェーズ開始時 |
/grill-with-docs | CONTEXT.md を参照して用語・ドメイン整合性を検証 | ドメインモデルに関わる機能実装前 |
推奨フロー:
1. 要件を受け取る
2. /grill-me で曖昧な点を質問（ユーザーと対話）
3. /grill-with-docs で用語・ドメインの整合性を確認
4. 計画立案へ進む
プロジェクトに CONTEXT.md がある場合、/grill-with-docs が用語集・ドメインモデルを参照して検証を行う。
プロジェクト立ち上げワークフロー
0. 計画検証（grill）
→ /grill-me, /grill-with-docs で要件の曖昧さを解消
1. 要件整理
→ 機能要件・非機能要件の整理、制約の確認
2. 技術選定
→ FW/言語・インフラ・アーキテクチャの選択
3. 全体設計
→ システム構成・データモデル・API 設計の方針
4. タスク分解
→ 実装タスクの洗い出しと優先順位付け
5. 委譲と進行管理
→ 専門スキルへの委譲、成果物の品質確認
6. 並列開発セットアップ（並列開発時）
→ feature ブランチ作成、worktree 基盤準備、BE/FE 統括への委譲
7. 横断レビューと統合（並列開発時）
→ BE/FE 成果物の整合性確認、feature → develop のマージ管理
場面別スキル使用ガイド
統括スキル
| 場面 | 使用スキル | 判断基準 |
|---|
| フロントエンド全般の方針決定 | /frontend-orchestrator | UI を含む機能開発の統括が必要な時 |
| バックエンド全般の方針決定 | /backend-orchestrator | API/サーバー開発の統括が必要な時 |
FW/ツール固有スキル
| 場面 | 使用スキル | 判断基準 |
|---|
| Next.js App Router での実装 | /nextjs-app-router | FE 統括から委譲される |
| Hono (TypeScript) での実装 | /hono-backend | BE 統括から委譲される |
| Gin (Go) での実装 | /gin-backend | BE 統括から委譲される |
| FastAPI (Python) での実装 | /fastapi-backend | BE 統括から委譲される |
| Vitest でのテスト実装 | /vitest-testing | TypeScript テスト実装時 |
| pytest でのテスト実装 | /pytest-testing | Python テスト実装時 |
| go test でのテスト実装 | /gotest-testing | Go テスト実装時 |
横断的関心事スキル
| 場面 | 使用スキル | 判断基準 |
|---|
| API 設計・DDD 構造設計 | /api-design | 新規 API やドメインモデル設計時 |
| DB テーブル設計 | /db-design | データモデル設計、マイグレーション時 |
| セキュリティ対策 | /web-security | 脆弱性レビュー、セキュリティ設計時 |
| 認証/認可の設計 | /auth-design | 認証フロー設計、認可モデル選択時 |
| ログ・メトリクス・トレース設計 | /observability | 可観測性の設計、ログ設計時 |
| アクセシビリティ設計 | /accessibility | WCAG 準拠、a11y 対応が必要な時 |
| 環境設定管理 | /env-config | 環境変数設計、設定管理方針の決定時 |
| テスト設計・戦略 | /test-design | テスト方針決定、テストレベル選択時 |
| バグ調査・問題切り分け | /debugging | 原因不明のバグ、パフォーマンス問題時 |
| CI/CD 構築 | /cicd-github-actions | パイプライン構築、自動化設定時 |
| モノレポ管理 | /pnpm-monorepo | ワークスペース設定、パッケージ追加時 |
| UI デザイン | /frontend-design | デザイン品質が重要な場面 |
| 設計セカンドオピニオン・厳格レビュー | /codex-cli | 重要な設計判断やセキュリティレビューで別 AI の視点が欲しい時 |
タスク分解と委譲の原則
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 を活用し、未完成でもマージ可能にする
並列開発ワークフロー
前提条件
- GitHub リポジトリが存在すること
claude コマンド（Claude Code CLI）が利用可能であること- git worktree が使用可能であること
- git worktree の技術的な操作ガイドとして
/git-worktree スキルを参照すること
並列開発の適用判断
タスク数が 2 以上 かつ ファイル競合なしで分割可能？
├→ Yes → 並列開発を適用
│ ├→ BE + FE に分かれる → BE/FE orchestrator に委譲
│ └→ 単一領域のみ → 該当 orchestrator に委譲
└→ No → 通常の逐次委譲
モデル使い分け
| 役割 | モデル | 理由 |
|---|
| オーケストレータ（project/BE/FE） | Opus | 要件整理・設計判断・レビューなど高度な推論が必要 |
| 実装エージェント（worker/fix） | Sonnet | コード生成・定型実装に最適、コスト効率が良い |
claude 起動時のモデル指定:
オーケストレータ: claude --model opus
実装エージェント: claude --model sonnet
3フェーズ概要
| フェーズ | 担当 | モデル | 内容 |
|---|
| Phase 1: 計画 | project-orchestrator + BE/FE orchestrator | Opus | 要件整理・タスク分割・worktree 作成・スラッシュコマンド生成 |
| Phase 2: 実装 | エキスパートエージェント（非対話） | Sonnet | worktree 内で自律実装・品質ゲート・プッシュ |
| Phase 3: レビュー | BE/FE orchestrator → project-orchestrator | Opus | レビュー・fix 指示・rebase/マージ・横断レビュー |
詳細は references/parallel-dev-workflow.md を参照。
※ Phase 1（設計判断）および Phase 3（レビュー）で、重要度が高い場面では /codex-cli を活用してセカンドオピニオンを取得する。
PR 作成ワークフロー
各タスクブランチの作業完了後、PR を作成して feature ブランチにマージする:
1. 作業完了 → 最終コミット + push
2. rebase で feature ブランチの最新を取り込み
3. テスト・lint が通ることを確認
4. force-with-lease で push
5. gh pr create --base feature/{機能名} で PR を作成
6. PR レビュー → 承認 → マージ
gh コマンドが使えない環境の場合は、ユーザーに PR 作成 URL と推奨内容を提示する。
詳細な手順は /git-worktree スキルの「PR 作成」セクションを参照。
ブランチ戦略 + worktree 構成
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/
project-orchestrator 自身の責務
-
feature ブランチの作成
git checkout develop && git pull origin develop
git checkout -b feature/{機能名}
git push -u origin feature/{機能名}
-
.gitignore への .worktrees/ 追加（初回のみ）
echo ".worktrees/" >> .gitignore
git add .gitignore && git commit -m "chore: .worktreesをgitignoreに追加"
mkdir -p .worktrees
-
タスクを BE/FE に振り分けて各オーケストレータに委譲
-
BE/FE オーケストレータの成果物を横断レビュー
- BE/FE の API インターフェース整合性
- 共有型定義の一致
- 認証/認可フローの一貫性
- エラーハンドリング方針の統一
-
feature → develop のマージ管理
-
クリーンアップの案内
BE/FE オーケストレータへの委譲フォーマット
=== 並列開発: {BE/FE} タスク委譲 ===
feature ブランチ: feature/{機能名}
【タスク一覧】
1. task/{作業名1}
- 概要: {概要}
- 使用スキル: /{スキル名}
- 依存: なし
- 仕様:
- {仕様項目}
2. task/{作業名2}
- 概要: {概要}
- 使用スキル: /{スキル名}
- 依存: task/{作業名1} 完了後
- 仕様:
- {仕様項目}
【依頼事項】
1. 各タスクの worktree + タスクブランチを作成
2. 各タスクの worker スラッシュコマンドを生成
3. レビュー → rebase → feature ブランチへのマージ
4. 完了後 project-orchestrator に報告
メインリポジトリ編集禁止ルール
- 各エキスパートは専用 worktree 内でのみ作業する
- メインリポジトリ（プロジェクトルート）のファイル編集は禁止
- ファイルパスは worktree ルートからの相対パスで指定する
pwd で worktree 内であることを確認してから作業する
こまめなコミットの徹底
実装エージェント（worker）およびレビュー修正エージェント（fix）は、作業中にこまめにコミットすること。
- 意味のある変更単位ごと（1 ファイル or 1 機能のまとまり）にコミット
- テストが通る状態になったタイミングでコミット
- 長時間の作業では 15〜30 分ごとを目安に中間コミット
- レビュー修正時は修正項目ごとにコミット
理由: 並列開発ではコンフリクトリスクが高く、こまめなコミットにより解消が容易になる。また障害時のロールバック単位が小さくなり、レビュー差分も読みやすくなる。
参照リンク
技術選定の判断フレームワーク
FW/言語選定
フルスタック 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
※ 並列開発時は、ステップ 7〜10 を /backend-orchestrator と /frontend-orchestrator に委譲し、worktree ベースで並列実行する。横断レビュー（BE/FE 整合性確認）は project-orchestrator 自身が担う。
