| name | teamworks |
| description | Agent Teamsを用いたチーム体制を設計・提案するスキル。実装フェーズ開始前に呼び出し、必要なSection（Product Design / Product Build）・メンバー構成をユーザーへ提示し承認を取得する。 |
| disable-model-invocation | true |
Agent Teams チーム体制構成
目標
選定する体制は常に以下の3軸を満たすこと:
- 高品質 — 欠陥・手戻りを最小化する実装品質
- 最適コスト — 不要なメンバー・工数を排除（YAGNI）
- ユーザー満足度最高 — Product Design SectionのUATで品質検証
⚠️ HARD-GATE（必須制約）
チーム体制をユーザーへ提示し、明示的な承認を得るまで、以下を一切実行してはならない:
- コードの記述・編集
- ファイルの作成・変更
- スキャフォールディング
- その他すべての実装作業
プロジェクトの見た目の複雑さに関わらず、すべてのケースに適用される。
実行ワークフロー
- 分析 — プロジェクトのコードベース・要件・タスクを把握する
- Section選定 — 後述の「利用可能なSection」を参照し、必要なSectionを選択する（1つ以上、複数可）
- メンバー設計 — 選定した各SectionのSection Leaderを必ずアサインし、タスク量・難易度に応じてメンバーの役割・人数を決定する
- 体制提示 — 以下のフォーマットでユーザーへ提示する
- 承認取得 → 承認後に実装フェーズへ移行
提示フォーマット
## 提案チーム体制
### プロジェクト規模
| レベル | 判定根拠 |
|--------|----------|
| Level X: [レベル名] | [具体的な判定理由] |
### 選定Section
- **[Section名]**: [選定理由]
### メンバー構成
| ロール | 人数 | 担当タスク | 利用Skills | MCP Servers | AgentType |
|--------|------|-----------|------------|-------------|-------------|
| [ロール名] | [N]名 | [タスク詳細(箇条書き)] | [Skills] | [MCP Servers] | [AgenType] |
### タスク配分
[ロール名]
├── [タスク1]
└── [タスク2]
### コミュニケーション経路
[Section間・メンバー間の報告・連絡の流れ]
### 体制根拠
[この体制を選んだ理由・考え方]
### 品質検証
| チェック項目 | 結果 |
|--------------|------|
| [項目] | [結果] |
---
## 承認
上記のチーム体制で実装を開始してよろしいでしょうか？
- [ ] はい、承認します
- [ ] いいえ、修正が必要です：___________
アンチパターン
「シンプルだから体制提示を省略する」は厳禁。
手戻りを生む典型的な失敗例:
- Section LeaderなしでSectionを構成する
- 目標3軸（品質・コスト・満足度）を考慮しない
- Sectionへの依頼タスクが不明確
- 不要なメンバーを追加する（YAGNI違反）
- 体制承認なしに実装を開始する
- メンバー構成には利用Skills、MCP Server、AgentTypeの不記載
利用可能なSection
各Sectionには必ず Section Leaderを1名 アサインすること。
1. Product Design Section
| 項目 | 内容 |
|---|
| Section Leader | Product Owner |
| 役割・目標 | ユーザー満足度最高のプロダクト設計・UAT実施・フィードバック連携 |
| 選定基準 | UI/UX設計・E2Eテスト・受入テストが必要なプロジェクト |
2. Product Build Section
| 項目 | 内容 |
|---|
| Section Leader | Develop Leader |
| 役割・目標 | ビジネス要件・システム要件に基づく高品質・最適コストの実装。Section内テスト完了後、Product Design SectionへUATを依頼する |
| 選定基準 | フロントエンド・バックエンド・アーキテクチャ設計を伴うプロジェクト |
メンバープロフィール
Product Design Section
Product Owner（1名固定）
- 役割: Section全体リード。メンバーへの具体的指示・不明点のユーザーへの問い合わせを担う
- コミュニケーション: Product Build Sectionとの連携は
Develop Leader のみと行う。Build Sectionメンバーへの直接指示は禁止
- AgentType:
analyzer
- Skills:
ultrathink, sequential-thinking
- MCP Servers:
perplexity
E2E Member（上限3名）
- 役割: Product OwnerからアサインされたE2Eテストタスクを高品質・高効率で実行する
- コミュニケーション:
Product Owner のみへ報告。他メンバーへの直接指示は禁止
- AgentType:
qa
- Skills:
ui-ux-pro-max, chrome-devtools
- MCP Servers:
zai-mcp-server, chrome-devtools
Product Build Section
Develop Leader（1名固定）
- 役割: Section全体リード。メンバーへの具体的指示・Product Ownerからの指摘対応・メンバー課題へのフィードバックを担う。不明点はMCP Serverを介してWeb調査し、まとめた内容をメンバーへ共有する。Developer間の作業を調整する。メンバーの実装コードに対してレビューを実施する。
- コミュニケーション: Product Design Sectionとの連携は
Product Owner のみと行う。Design Sectionメンバーへの直接指示は禁止
- AgentType:
multi-agent-coordinator
- Skills:
ultrathink, sequential-thinking, tailwind-design-system, ui-ux-pro-max, vercel-react-best-practices, error-handling-patterns, fastapi-templates, microsoft-agent-framework
- MCP Servers:
perplexity, context7, zai-mcp-server
Frontend Developer（上限3名）
- 役割: UI/UX・React・Tailwindなどフロントエンド実装を担う
- 制約: 同一ファイルへの複数名同時編集は禁止
- コミュニケーション:
Develop Leader のみへ報告。他メンバーへの連絡は必ず Develop Leader を経由する
- AgentType:
frontend
- Skills:
tailwind-design-system, ui-ux-pro-max, vercel-react-best-practices, error-handling-patterns, chrome-devtools
- MCP Servers:
perplexity, context7, github, zai-mcp-server, chrome-devtools
Backend Developer（上限3名）
- 役割: Python・Java・データベース設計などバックエンド実装を担う
- 制約: 同一ファイルへの複数名同時編集は禁止
- コミュニケーション:
Develop Leader のみへ報告。他メンバーへの連絡は必ず Develop Leader を経由する
- AgentType:
frontend
- Skills:
fastapi-templates, microsoft-agent-framework, error-handling-patterns
- MCP Servers:
perplexity, context7
System Architect（1名固定）
- 役割: システムアーキテクチャ設計専任。コード実装は行わず、適切な設計をDevelop Leaderへ提案・共有する
- 制約: 活動時は必ず
architect ロールへ切り替えること
- コミュニケーション:
Develop Leader のみへ報告。他メンバーへの連絡は必ず Develop Leader を経由する
- Skills:
fastapi-templates, microsoft-agent-framework, tailwind-design-system, ui-ux-pro-max, vercel-react-best-practices, error-handling-patterns
- MCP Servers:
perplexity, context7
Progressive Disclosure（段階的体制選定）
プロジェクトの複雑さに応じて、体制を段階的に構築すること。
複雑さレベル判定
| レベル | 特徴 | 選定Section | メンバー数 |
|---|
| Level 1: シンプル | 1〜3ファイルの修正・既存パターン準拠・テスト変更なし | Product Buildのみ | 1〜2名 |
| Level 2: 標準 | 複数ファイル・新規機能・テスト必要・UI変更小 | Build + （必要時）Design | 2〜4名 |
| Level 3: 複雑 | アーキテクチャ変更・新技術導入・大規模UI変更 | Build + Design + Architect | 4名以上 |
判定フロー
1. 変更ファイル数は3以下か？
→ Yes: Level 1（Buildのみ、1名）
→ No: 次へ
2. UI/UX変更または新規画面は必要か？
→ Yes: Design Section追加
3. データベース設計またはAPI設計の変更は必要か？
→ Yes: Build SectionにBackend Developer追加
4. 新技術導入またはアーキテクチャ変更は必要か？
→ Yes: System Architect追加
5. E2EテストまたはUATは必要か？
→ Yes: Design SectionにE2E Member追加
適用例
| シナリオ | レベル | 選定Section | メンバー構成 |
|---|
| バグ修正（APIエンドポイント1箇所） | Level 1 | Build | Develop Leader + Backend Developer 1名 |
| 新規CRUD画面実装 | Level 2 | Build + Design | Develop Leader + Frontend 1名 + Backend 1名、Product Owner |
| 認証システム全面刷新 | Level 3 | Build + Design + Architect | 全ロール活用 |
Validationチェックリスト
体制提案前に必ず以下を確認すること。
必須チェック（すべて満たすこと）
| # | 項目 | 確認方法 |
|---|
| 1 | Leader確保 | 各SectionにSection Leaderが1名以上いるか？ |
| 2 | YAGNI遵守 | 不要なメンバー・Sectionが含まれていないか？ |
| 3 | スキル充足 | 必要なSkills/MCP Serversをメンバーが網羅しているか？ |
| 4 | 通信経路 | Section間の連絡経路が明確か？ |
| 5 | HARD-GATE | 承認前に実装作業を開始していないか？ |
| 6 | タスク明確性 | 各メンバーの担当タスクは具体的に記述されているか？ |
| 7 | 並列可能性 | 同一ファイルへの複数メンバーアサインはないか？ |
| 8 | 見積もり妥当性 | 工数見積もりとメンバー数のバランスは適切か？ |
| 9 | フォールバック | メンバーが失敗した場合の対応策はあるか？ |
| 10 | スコープ明確性 | 各Sectionの責任範囲は重複なく明確か？ |
自己検証プロンプト
体制提案前に以下を自問し、回答を記述すること：
「この体制で実装した場合、品質・コスト・満足度のどれが損なわれる可能性があるか？」
- 品質リスク: ___________
- コストリスク: ___________
- 満足度リスク: ___________
「ユーザーがこの体制を見て、納得せずに修正を求めるポイントはどこか？」
- 予想される質問: ___________
- 事前準備すべき回答: ___________
Key Principles
| 原則 | 内容 |
|---|
| 体制具体化 | どのSection・メンバー・ロールかを明確にする |
| 体制理由説明 | 体制構成の根拠を必ず説明する |
| YAGNI徹底 | 不要なSection・メンバーを追加しない |
| Leaderルール | 選定した各SectionにSection Leaderを必ずアサインする |
| コミュニケーション厳守 | Section間通信はリード同士のみ。メンバーの直接横断通信は禁止 |
| 利用Skills, MCP Server, AgentTypeの明示提示 | 体制内の各teammatesは利用する予定のSkillsとMCP Servers、AgentTypeを明確に提示する。メンバープロフィールに定義した各メンバーが保持しているSkillsとMCP Servers、AgentType以外に定義することが厳禁。 |
| 提示フォーマット徹底 | 必ず提示フォーマットに基づき体制提案を出力する |
