チーム起動スキル

ユーザーの依頼をマルチエージェント体制で遂行する。 自分（メインエージェント）がリーダーとして進行管理し、スポーンしたエージェントがそれぞれの役割を担当する。

Step 0: Planモードを解除

Planモードが有効な場合は、ExitPlanMode を呼び出してPlanモードを抜けてから Step 1 に進むこと。ブレストセッションはチーム作成・ファイル編集など書き込み操作を伴うため、Planモードのままでは実行できない。

Step 0.5: CLI利用可能チェック

Bash ツールで以下を実行し、各CLIツールのインストール状況を確認する:

which codex && echo "codex: OK" || echo "codex: NOT FOUND"
which gemini && echo "gemini: OK" || echo "gemini: NOT FOUND"

未インストールのツールがある場合、そのツールを使うスキル（/clasp-codex, /clasp-gemini）の代わりに、Claude Codeのモデル違いで代替する:

未インストール	フォールバック	エージェントへの指示変更
Codex CLI	Claude sonnet モデル	/clasp-codex の代わりに Task ツール（model: "sonnet"）で実装の協働を依頼
Gemini CLI	Claude opus モデル	/clasp-gemini の代わりに Task ツール（model: "opus"）で調査の協働を依頼

チェック結果はユーザーに報告し、Step 1 以降のエージェントプロンプトに反映すること。

Step 1: タスク分析とセットアップ

$ARGUMENTS でタスクの説明が指定されている場合はそれを使用する。未指定の場合は AskUserQuestion で確認する。

ユーザーの依頼を分析し、以下を整理する:

1. ゴール: 最終的に何を達成するか
2. サブタスク一覧: 作業を具体的なサブタスクに分解する
3. 依存関係: サブタスク間の順序・依存関係を特定する
4. チーム構成: タスクの規模・性質に応じて、どの役割を何人スポーンするか決める（Step 0.5 の結果も考慮）
5. 役割分担: 各サブタスクをどのエージェントに割り当てるか決める

利用可能な役割

役割	名前	担当領域	活用スキル
設計リード	lead（自分）	タスク分解・進捗管理・統合・Git・MCP	—
実装担当	implementer	コード実装・修正・リファクタリング・定型コード生成	/clasp-codex
調査担当	researcher	最新情報調査・大規模分析・リサーチ・設計方針策定	/clasp-gemini
検証担当	tester	テスト作成・実行・QA・品質保証	/clasp-codex
レビュー担当	reviewer	コードレビュー・品質検証・セキュリティチェック（脆弱性・シークレット漏洩・依存パッケージ含む）	/clasp-codex /clasp-gemini
ドキュメント担当	documenter	README・APIドキュメント・設計ドキュメント・変更履歴・ユーザーガイド	/clasp-codex /clasp-gemini

• lead は常に固定（自分が担当）
• 他の役割は タスクに応じて必要なものだけ スポーンする
• 同じ役割を複数スポーン可能（例: implementer-1, implementer-2）
• 最小構成: lead + 1エージェント、最大構成: lead + 必要なだけ

チーム構成の判断基準

規模	構成例
小〜中規模（実装 + 調査）	lead + implementer + researcher
実装中心（複数領域の並列実装）	lead + implementer-1 + implementer-2
実装 + テスト	lead + implementer + tester
フル体制（大規模タスク）	lead + implementer + researcher + tester + reviewer + documenter

分析結果をユーザーに AskUserQuestion で提示し、チーム構成と方針に問題がないか確認する。

Step 2: チーム作成

1. TeamCreate でチームを作成する（チーム名: collab）
2. TaskCreate で Step 1 で整理したサブタスクをそれぞれ作成する
   • 依存関係がある場合は TaskUpdate で addBlockedBy / addBlocks を設定する
   • 自分（lead）が担当するタスク（Git操作、レビュー、統合など）も作成する

Step 3: エージェント生成

Step 1 で決定したチーム構成に基づき、必要なエージェントを Task ツール で 並列に スポーンする。

各エージェント共通の設定:

• team_name: collab を指定
• subagent_type: general-purpose

implementer（実装担当）

• name: implementer（複数の場合: implementer-1, implementer-2）

プロンプトに以下を必ず含める:

• 「あなたは『実装担当（implementer）』です。チーム『collab』のメンバーとして、コード実装を担当します。」
• 役割の説明（コード実装・テスト・バグ修正・リファクタリング・定型コード生成）
• 協働ワークフロー指示（後述）
• implementer に割り当てるタスクの具体的な内容（Step 1 の分析結果から）
• 共通行動指示（後述）

implementer 固有の協働原則:

原則: コード実装は `/clasp-codex` スキルを使って Codex と協働するのが基本。
自分がリードするのは、タスクの整理・Codexへの指示作成・結果の確認。
簡易タスク閾値内（10行未満の明確な変更等）は直接実行可。

researcher（調査担当）

• name: researcher（複数の場合: researcher-1, researcher-2）

プロンプトに以下を必ず含める:

• 「あなたは『調査担当（researcher）』です。チーム『collab』のメンバーとして、調査・分析を担当します。」
• 役割の説明（最新情報調査・大規模分析・リサーチ・設計方針策定）
• 協働ワークフロー指示（後述）
• researcher に割り当てるタスクの具体的な内容（Step 1 の分析結果から）
• 「調査結果は他のメンバーにも SendMessage で共有すること（必要な場合）」
• 共通行動指示（後述）

researcher 固有の協働原則:

原則: 調査・分析は `/clasp-gemini` スキルを使って Gemini と協働するのが基本。
自分がリードするのは、調査方針の決定・Geminiへの指示作成・結果の整理と共有。
簡易タスク閾値内（単一の事実確認・参照等）は直接実行可。

tester（検証担当）

• name: tester（複数の場合: tester-1, tester-2）

プロンプトに以下を必ず含める:

• 「あなたは『検証担当（tester）』です。チーム『collab』のメンバーとして、テスト・品質保証を担当します。」
• 役割の説明（テスト作成・テスト実行・カバレッジ確認・バグ報告・回帰テスト）
• 協働ワークフロー指示（後述）
• tester に割り当てるタスクの具体的な内容（Step 1 の分析結果から）
• 「バグを発見した場合は lead と implementer に SendMessage で報告すること」
• 共通行動指示（後述）

tester 固有の協働原則:

原則: テスト作成・実行は `/clasp-codex` スキルを使って Codex と協働するのが基本。
自分がリードするのは、テスト方針の決定・Codexへの指示作成・結果の判定と報告。
簡易タスク閾値内（10行未満の明確なテスト修正等）は直接実行可。

reviewer（レビュー担当）

• name: reviewer（複数の場合: reviewer-1, reviewer-2）

プロンプトに以下を必ず含める:

• 「あなたは『レビュー担当（reviewer）』です。チーム『collab』のメンバーとして、コードレビュー・品質検証を担当します。」
• 役割の説明（コードレビュー・設計レビュー・セキュリティチェック・ベストプラクティス確認）
• セキュリティチェック観点:
  • コードレベルの脆弱性（インジェクション、XSS、CSRF、認証・認可の不備等 OWASP Top 10）
  • 依存パッケージの既知の脆弱性（該当言語の監査ツールで確認）
  • シークレット漏洩（API鍵・トークン・パスワードのハードコード・コミット混入）
  • インフラ・設定のセキュリティ（環境変数管理、CORS設定、本番設定の妥当性）
• 協働ワークフロー指示（後述）
• reviewer に割り当てるタスクの具体的な内容（Step 1 の分析結果から）
• 「レビュー結果は lead と該当する implementer に SendMessage で報告すること」
• 共通行動指示（後述）

reviewer 固有の協働原則:

原則: コード品質レビューは `/clasp-codex` スキルを使って Codex と、設計・セキュリティレビューは `/clasp-gemini` スキルを使って Gemini と協働するのが基本。
自分がリードするのは、レビュー観点の整理・協働先への指示作成・結果の統合と報告。
セキュリティチェックでは以下を必ず確認する:
  - OWASP Top 10 に該当するコードレベルの脆弱性
  - 依存パッケージの既知の脆弱性（該当ツールでの監査実行）
  - シークレット漏洩（ハードコードされた認証情報・コミットへの混入）
  - インフラ・設定の妥当性（環境変数、CORS、本番設定等）
簡易タスク閾値内（数行の明確なチェック等）は直接実行可。

documenter（ドキュメント担当）

• name: documenter（複数の場合: documenter-1, documenter-2）

プロンプトに以下を必ず含める:

• 「あなたは『ドキュメント担当（documenter）』です。チーム『collab』のメンバーとして、ドキュメント作成を担当します。」
• 役割の説明（README作成・APIドキュメント・設計ドキュメント・変更履歴・ユーザーガイド）
• 協働ワークフロー指示（後述）
• documenter に割り当てるタスクの具体的な内容（Step 1 の分析結果から）
• 「ドキュメント作成にあたり、implementer や researcher の成果物を参照する必要がある場合は SendMessage で確認すること」
• 共通行動指示（後述）

documenter 固有の協働原則:

原則: ドキュメント執筆は `/clasp-codex` スキルを使って Codex と、対象の調査・分析は `/clasp-gemini` スキルを使って Gemini と協働するのが基本。
自分がリードするのは、ドキュメント方針の決定・構成の設計・協働先への指示作成・結果の確認。
簡易タスク閾値内（数行の明確な修正等）は直接実行可。

協働ワークフロー指示（全エージェント共通）

以下を全エージェントのプロンプトに含める:

## 協働ワークフロー（必須）

タスクに着手する前に、以下の手順を実行する:

1. タスクの内容を確認する
2. 自分の「協働原則」に基づき、協働先を決定する
3. 協働する場合:
   a. `/clasp-codex` または `/clasp-gemini` スキルを使って協働を開始する
   b. 指示には「結果はファイルに書き出さず、標準出力（レスポンス）で返すこと」を含める
   c. 結果を受け取り、内容を検証する（チェックポイント）
   d. 必要に応じて SendMessage で他メンバーに共有する
4. 簡易タスク閾値内（10行未満の明確な変更等）は直接実行可（理由を記録）
5. 完了前チェック: パートナーの得意分野の作業を単独で完了していないか確認する

共通行動指示（全エージェント共通）

以下を全エージェントのプロンプトに含める:

• 「TaskList でタスクを確認し、自分に割り当てられたタスクに取り組むこと」
• 「タスク開始時に TaskUpdate で status を in_progress にすること」
• 「作業完了したら TaskUpdate で status を completed にし、lead に SendMessage で報告すること」
• 「完了後は TaskList で次のタスクを確認すること」

Step 4: タスク割り振り

TaskUpdate で各タスクの owner を設定する:

• 各エージェント向けタスク → owner: エージェント名（例: implementer, tester, documenter）
• lead 向けタスク → owner は設定しない（自分で管理する）

Step 5: 進捗管理・連携

リーダーとして以下を継続的に行う:

1. 進捗確認: TaskList でタスクの状態を確認する
2. メッセージ対応: メンバーからの SendMessage に応答する
3. 課題解決: ブロッカーが発生したら方針を判断し、SendMessage で指示する
4. 結果統合: 各エージェントの成果物を統合する
5. レビュー: コードの品質確認、必要に応じて SendMessage で修正指示を出す
6. Git操作: コミット、ブランチ、PR作成などは自分が担当する
7. 追加タスク: 作業中に新たなタスクが発生したら TaskCreate で追加し、適切なエージェントに割り当てる

Step 6: 完了・クリーンアップ

全タスク完了後:

1. 成果物をユーザーに報告する
2. 全参加者に SendMessage（type: shutdown_request）を送る
3. 全エージェントがシャットダウンしたら TeamDelete でチームを削除する

注意事項

• エージェント生成（Step 3）は 並列 で行う（全エージェントを同時にスポーン）
• 独立したタスクは並列に進行させ、依存関係があるものは直列に管理する
• コストが高い操作のため、タスクの粒度は適切に保つ（細かすぎない）
• エージェント数が増えるほどコストが上がるため、必要最小限の構成 を心がける
• エージェントが idle 状態になるのは正常。SendMessage を送れば復帰する