無料GitHub で公開

team-plan

実装タスクを受け取ったとき、5つの専門エージェントチームでコードベースを調査・議論し、 AI 間の合意形成を経て Plan Mode で実装計画を作成する。不明点はユーザーに質問し、完璧な計画を立ててから実装する。バグ修正・新機能・リファクタリング・設定変更など、あらゆる実装タスクに対応。 Use when: 実装を始める前に調査が必要なとき、影響範囲が不明なとき、複数ファイルにまたがる変更をするとき、慎重に計画を立ててから実装したいとき。 Triggers: "調査してから実装", "team plan", "まず調査", "影響範囲を調べて", "計画を立ててから", "plan before implement", "コードベースを調査して実装", "research first", "調査→計画→実装"

sean-sunagaku/claude-code-plugin

インストール方法を見る

含まれるファイル（1）

SKILL.md10.4 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Team Plan

5つの専門エージェントがチームでコードベースを調査・議論し、 AI 間で十分に話し合って合意形成した上で Plan Mode の実装計画を作成する。不明点はユーザーに質問し、手戻りのない計画を目指す。

ワークフロー概要

Step 1: タスク受領・チーム作成
Step 2: 並列調査（researcher + analyst + pattern-expert）
Step 3: 議論・合意形成（architect 主導、全員参加）
        ↳ 不明点 → リーダー経由でユーザーに質問 → 回答を共有
Step 4: 計画書作成（plan-writer → 全員レビュー）
Step 5: Plan Mode（リーダーが計画書をもとに作成、ユーザー承認）
Step 6: 実装（承認後）
Step 7: クリーンアップ

Step 1: タスク受領・チーム作成

1a: フルチーム起動 vs スキップ

フルチーム起動（1つでも該当すれば）:

複数ファイルにまたがる変更
影響範囲が不明
複数のアプローチが考えられる
既存の設計パターンの理解が必要

スキップ条件（以下を全て満たす場合は直接 EnterPlanMode へ）:

変更対象のファイルパスがユーザーから明示されている
単一ファイル内の 1〜3 行の変更（typo 修正・定数値の変更等）
他のファイルへの影響が明らかにない

「簡単そうだから」という主観的な判断でのスキップは禁止。

1b: チーム作成

TeamCreate で team-plan チームを作成。

name	役割	視点	主な手段
`code-researcher`	コードベース調査・既存実装の把握	「何がある」	Read, Grep, Glob, Task(全タイプ)
`dependency-analyst`	依存関係・影響範囲・リスク評価	「何が壊れる」	Read, Grep, Glob, Task(全タイプ), WebSearch, WebFetch
`pattern-expert`	類似パターン・命名規則・慣例分析	「どう書くべき」	Read, Grep, Glob, Task(全タイプ)
`solution-architect`	実装方針設計・議論リード・合意形成	「どう実装する」	Read, Grep, Glob, WebSearch
`plan-writer`	議論の統合・計画書の執筆	「どう伝える」	Read, Grep, Glob, Write, Edit

1c: タスク作成

TaskCreate で6つのタスクを作成:

code-researcher: コードベース調査（依存なし）
dependency-analyst: 依存関係・影響分析（依存なし）
pattern-expert: 類似パターン・慣例分析（依存なし）
solution-architect: 実装方針設計・議論リード（addBlockedBy: ["1","2","3"]）
plan-writer: 計画書作成（addBlockedBy: ["4"]）
team-lead: Plan Mode 作成（addBlockedBy: ["5"]）

1d: エージェント起動

5エージェントを 1つのメッセージで並列に Task ツールで起動する。

subagent_type: "team-plan:{role-name}"
team_name: "team-plan"
name: "{role-name}"
mode: "bypassPermissions"
run_in_background: true

プロンプトに含める情報（省略禁止）:

ユーザーのタスク説明（原文をそのまま）
作業ディレクトリの絶対パス
計画書の出力先パス: {作業ディレクトリ}/.claude/team-plan-output/plan.md
CLAUDE.md のプロジェクト固有ルール（あれば要約）
チームメンバー一覧（名前と役割）

Step 2: 並列調査フェーズ

Round 1（並列）:
  code-researcher  → 変更対象のファイル・関数・クラスを特定
  dependency-analyst → 依存関係マッピング、影響範囲分析
  pattern-expert    → 類似実装、命名規則、コードベースの慣例を分析

3エージェントが並列に調査し、それぞれの調査結果を solution-architect に共有する。リーダーは待機。

Step 3: 議論・合意形成フェーズ

Round 2（議論）:
  solution-architect → 調査結果を統合し実装方針を提案（broadcast）
  code-researcher    → 方針に対するフィードバック（見落としファイル等）
  dependency-analyst → リスク観点からの批判的レビュー
  pattern-expert     → 慣例・パターンとの整合性をチェック
  solution-architect → フィードバックを踏まえて方針を修正・再提案

ユーザー質問エスカレーションプロトコル

議論の過程で「ユーザーに確認が必要」と判断された場合:

エージェント → team-lead に以下の形式で SendMessage:

[USER-QUESTION]
質問: {質問内容}
背景: {なぜこの情報が必要か}
選択肢（あれば）:
- A: {選択肢A}
- B: {選択肢B}

リーダー → ユーザー に AskUserQuestion で質問
リーダー → 全エージェント に broadcast でユーザーの回答を共有:

SendMessage(
  type: "broadcast",
  content: "[USER-ANSWER] {質問者} の質問に対するユーザーの回答:
{回答内容}
引き続き議論を進めてください。",
  summary: "ユーザー回答共有"
)

リーダーの行動ルール

見守りが基本: エージェントの議論には介入しない
介入タイミング:
- [USER-QUESTION] を受信した時 → ユーザーに質問して回答を返す
- 同じ議論が 3 往復以上繰り返される時 → 方向性を指示
- エージェントが blockedBy 待ちのまま進まない時 → 状況を確認
- 明らかに方向性がずれている時 → 軌道修正

Step 4: 計画書作成フェーズ

Round 3:
  plan-writer        → 議論の合意内容を計画書にまとめて書き出す
  solution-architect → 計画書をレビュー（方針との整合性）
  code-researcher    → 計画書をレビュー（ファイルパスの正確性）
  dependency-analyst → 計画書をレビュー（リスク対策の網羅性）
  pattern-expert     → 計画書をレビュー（慣例との整合性）
  plan-writer        → フィードバックを反映して最終化
  plan-writer        → team-lead に完成を報告

計画書は {作業ディレクトリ}/.claude/team-plan-output/plan.md に書き出される。

Step 5: Plan Mode

plan-writer から完成報告を受け取る
.claude/team-plan-output/plan.md を Read で読み込む
EnterPlanMode を呼び出す
計画書の内容を Plan ファイルに転記（必要に応じて補足・調整）
変更対象ファイルの該当箇所を Read で直接確認し、計画書との整合性を検証
ExitPlanMode でユーザーの承認を求める

Plan ファイルの構造

## 実装計画

### チーム調査・議論で判明した事項
- 既存構造の概要（変更対象ファイルと役割）
- 依存関係と影響範囲
- コードベースの慣例・パターン
- リスク・注意点
- ユーザーへの質問で確認した事項（あれば）

### 変更対象ファイル一覧
| ファイル | 変更内容 |
|---------|---------|
| {絶対パス} | {何をどう変えるか} |

### 実装ステップ（順序付き）
1. {具体的なステップ}
   - 対象: {ファイルパス}
   - 挿入位置の目印: {周辺コード・関数名}

### テスト計画
- {確認すべきこと}

### リスク・注意点
- {リスクと対策}

### 検討した代替案
- {採用しなかったアプローチとその理由}

Note: 行番号は参考情報。実装時は必ず Read でファイルを再確認すること。

Step 6: ユーザー承認後の実装

承認された場合

実装を開始する。以下のガイドラインに従う:

実装前に必ずファイルを再読み込みする: 編集対象のファイルは Edit の直前に必ず Read で最新内容を取得し、old_string に使う文字列を目視確認すること
行番号ではなくコンテキスト（周辺コード）で編集位置を特定する: Edit ツールの old_string には十分な周辺コンテキストを含める
計画通りのステップで実装する
計画外の変更が必要になった場合: 即座にユーザーに報告し、続けてよいか確認する
各ステップ完了後に簡潔に進捗を報告する
エラーが発生した場合は原因を分析し、計画の見直しを提案する

修正を求められた場合

EnterPlanMode に戻り、ユーザーのフィードバックをもとに計画を更新する。必要であればエージェントチームを再起動して追加調査。

Step 7: クリーンアップ

全エージェントに shutdown_request を送信
全員シャットダウン後に TeamDelete でチーム削除

注意事項

並列起動を徹底: 5エージェントを常に1メッセージで同時起動
Plan Mode を省略しない: チームの合意があっても必ず Plan Mode を経由してユーザーの承認を得る
ユーザー質問は必ずリーダー経由: エージェントは直接ユーザーに聞けない。リーダーが AskUserQuestion で橋渡しする
実装は Plan Mode 承認後: チーム議論中にコードを変更しない
Explore サブエージェント: 調査エージェント (code-researcher, dependency-analyst, pattern-expert) は Task(Explore) を自由に並列起動して調査を分担できる。体数制限なし
コスト意識: 軽微な変更にはスキップ条件を適用する

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

agent-team

無料

This skill should be used when the user asks to "create a team", "spawn agents", "parallel execution", "delegate tasks to agents", "use a swarm", "team workflow", "split work across agents", "run tasks in parallel", or mentions wanting multiple agents to collaborate on a complex task.

日本語の概要は準備中です。原文の説明を表示しています。