tomevault-io 開発チーム集合
このスキルはLLM agentであるリーダー（メインエージェント）が読み、チーム編成から実装完了までを自律的に進めるための指示書です。
概要フロー: フェーズ1（セットアップ）→ フェーズ2（プラン実装）→ フェーズ3（外部レビュー対応）
最短サイクル: 実装（implementer）→ レビュー（reviewer）+ リリース（release-manager）並列 → 次ステップ
反復前提: フェーズ2/3はチーム解散までユーザーの指摘に応じて繰り返し実行します。
禁止事項
- あなた（リーダー）は実装作業を行わない。タスク管理と調整のみ行う
- 一度に複数ステップを同時に実装させない。必ず1ステップずつ進める
- チームメンバーへの指示には、必ずプランファイルのパスと現在のステップ番号を含める
- チーム作成前にプランファイルの存在を確認する
- ユーザーの指示なしで勝手にチームを解散しない
- ユーザーに判断を仰ぐのは、メンバー間で意見が食い違うときや判断に迷うときのみ
- それ以外はリーダーが自律的に最後までタスクを進める
- プランファイルが見つからない場合はユーザーに報告して終了する
- メンバー間の通信はコミュニケーションパスのマトリクスに従う。許可されていない経路での直接通信は行わない
前提条件
.claude_work/plans/*.mdに有効なプランファイルが1つ存在すること- git worktree運用のため、単一のプランファイルが前提
チーム構成
| 役割 | 名前 | 目的 |
|---|---|---|
| リーダー（あなた） | - | タスク管理・全体調整・ステップ分解 |
| 実装担当 | implementer | プランの1ステップを実装 |
| リリース担当 | release-manager | semantic-committingでコミット作成 → updating-pr-title-and-descriptionでPR更新 → monitor-ciでCIチェック。CI失敗時はimplementerと連携して自律的に対応 |
| レビュー担当 | reviewer | プランファイルに基づく簡易レビュー |
| プラン更新担当 | plan-updater | ユーザーの指摘をプランファイルに反映 |
各担当の詳細指示は references/ ディレクトリを参照:
- 実装担当: references/implementer.md
- リリース担当: references/release-manager.md
- レビュー担当: references/reviewer.md
- プラン更新担当: references/plan-updater.md
コミュニケーションパス
リーダーをハブとした双方向通信構造。責任境界を明確にし、情報の流れを整理する。
| リーダー | implementer | reviewer | release-manager | plan-updater | |
|---|---|---|---|---|---|
| リーダー | - | ○ | ○ | ○ | ○ |
| implementer | ○ | - | ○ | ○ | - |
| reviewer | ○ | ○ | - | - | - |
| release-manager | ○ | △ | - | - | - |
| plan-updater | ○ | - | - | - | - |
通信ルール:
- リーダーは全員と通信可能（ハブ）
- implementer → reviewer/release-manager は直送可（実装完了の迅速報告のため）。ただし、直送時はリーダーにも同報すること（進捗把握のため）
- reviewer → implementer は指摘対応のため許可。指摘時はリーダーにも共有すること
- release-manager と plan-updater は原則リーダー経由のみ（責任線の明確化）
例外パス（△マーク）:
- CI失敗時: release-manager → implementer への直送を許可（迅速な修正対応のため）。ただし、リーダーへの状況報告は必須
実行手順
フェーズ1: 初期セットアップ
- 入力: ユーザーの「開発チーム集合」発言
- 処理: プラン特定 → チーム作成 → 分析 → タスク登録
- 出力: チーム稼働状態（4名スポーン完了 + タスクリスト作成済み）
1.1 プランファイルの特定
ls .claude_work/plans/*.md
プランファイルが存在しない場合はユーザーに報告して終了。
プランファイルのパスを以下のように定義:
<取得したプランファイルのパス>
1.2 チーム作成とメンバースポーン
TeamCreate でチームを作成（team_name: "dev-team-{セッションID短縮}"）
以下の共通テンプレートと役割別差分で4名をスポーン:
共通テンプレート:
あなたは開発チームの{役割名}です。
プランファイル: <plan-fileタグで定義されたパス>
詳細指示: まず {referencesファイルのパス} を Read ツールで読んでください。
そこに記載された手順に従って作業してください。
リーダーからの指示が来るまで待機してください。
作業完了後は必ずリーダーにメッセージで報告してください。
役割別差分:
| メンバー | 役割名 | referencesファイル | 待機内容 |
|---|---|---|---|
| implementer | 実装担当 | skills/assembling-dev-team/references/implementer.md | 各ステップの実装指示 |
| release-manager | リリース担当 | skills/assembling-dev-team/references/release-manager.md | リリース指示 |
| reviewer | レビュー担当 | skills/assembling-dev-team/references/reviewer.md | レビュー指示 |
| plan-updater | プラン更新担当 | skills/assembling-dev-team/references/plan-updater.md | プラン更新指示 |
1.3 プランファイルの分析
プランファイルを読み取り、実装ステップを分解する。 各ステップを TaskCreate でタスクリストに追加する。
フェーズ2: プラン実装（全ステップ完了まで）
- 入力: タスクリスト（フェーズ1で作成済み）
- 処理: 各ステップについて実装→レビュー+リリース（コミット・PR更新・CI）のサイクルを回す
- 出力: ユーザーへの「フェーズ2完了。レビューをお願いします」報告（PR URL含む）
2.1 ステップごとの実装サイクル
各ステップについて以下のサイクルを実行:
2.1.1 実装
- implementer にステップNの実装を依頼（SendMessage type: message）
- TaskUpdate でタスクを in_progress に更新
- implementer からの完了報告を待つ
実装依頼フォーマット:
implementer へ:
ステップ{N}の実装をお願いします。
プランファイル: <plan-fileタグのパス>
ステップ番号: {N}
プランファイルを読み取り、該当ステップの内容を実装してください。
完了したら報告してください。
2.1.2 レビューとリリース（並列実行）
- reviewer にステップNの実装レビューを依頼（SendMessage type: message）
- release-manager にステップNのリリースを依頼（SendMessage type: message）
- 両方からの報告を待つ
レビュー依頼フォーマット:
reviewer へ:
ステップ{N}の実装レビューをお願いします。
レビューフェーズ: フェーズ2（実装中）
プランファイル: <plan-fileタグのパス>
ステップ番号: {N}
**対象ファイル一覧**:
{implementerの完了報告から変更ファイル一覧を転記}
当該ステップの範囲のみを対象にレビューしてください。
指摘があれば具体的に報告してください。
リリース依頼フォーマット:
release-manager へ:
ステップ{N}の実装をリリースしてください（コミット→PR更新→CIの自律実行）。
プランファイル: <plan-fileタグのパス>
ステップ番号: {N}
**implementerの報告内容**:
変更ファイル一覧:
{implementerの完了報告から変更ファイル一覧を転記}
概要:
{implementerの完了報告から概要を転記}
以下の手順で自律的に進めてください：
1) semantic-committingでコミット作成
2) updating-pr-title-and-descriptionでPR更新
3) monitor-ciでCIチェック
すべて完了したら結果を報告してください。
2.1.3 指摘への対応
- reviewer から指摘がある場合: reviewer が implementer に直接指摘を送付し、リーダーにも共有する。リーダーは指摘内容を確認し、修正完了を追跡する → 修正完了後に再レビュー
- 指摘がない場合: TaskUpdate でタスクを completed に更新
2.1.4 次ステップへ
- 次のステップがあれば 2.1.1 に戻る
- 全ステップ完了なら 2.2 へ
2.2 全ステップ完了後の最終確認
release-managerからの最終報告（PR URL、CI結果）を確認し、ユーザーに結果を報告する。
- release-managerからの最終報告（PR URL、CI結果）を確認
- ユーザーに「フェーズ2完了。レビューをお願いします」と報告（PR URLを含む）
フェーズ3: 外部レビュー対応（指摘がなくなるまで）
- 入力: ユーザーやCodex等のチームメンバー以外からのレビュー指摘
- 処理: 指摘を振り分け（計画変更 → plan-updaterがプラン更新 / 実装修正 → 3-Aレビュー（3.1.1）→ 修正サイクル（3.2） / CI影響 → release-manager対応）
- 出力: 指摘対応完了報告
3.1 指摘の受け取りと振り分け
外部レビュー（ユーザー、Codex等チームメンバー以外からの指摘）の受け口は常にリーダーに集約する。他メンバーに直接届いた場合は、そのメンバーは自己判断で対応せず、リーダーにメッセージで転送すること。
リーダーが指摘を受け取ったら、以下の振り分けルールに従って対応先を判定する:
| 指摘の種類 | 対応先 | アクション |
|---|---|---|
| 計画変更が必要 | plan-updater | プランファイル更新を依頼 → 完了後にbroadcastで全メンバーに再読み込みを通知 → 必要に応じてタスクリスト更新（TaskCreate / TaskUpdate） |
| 実装の修正が必要 | reviewer → implementer | まずフェーズ3-Aレビュー（3.1.1）→ 修正サイクル（3.2）を実行 |
| CI/品質/リリースへの影響 | release-manager | release-managerに対応依頼（必要に応じて他メンバーにも同報） |
複数カテゴリにまたがる場合は、リーダーが優先順位をつけて順次対応する。
3.1.1 フェーズ3-Aレビュー（実装修正の前段）
「実装の修正が必要」と判断した場合、修正サイクル（3.2）に入る前に reviewer にフェーズ3-Aレビューを依頼する。reviewer の評価報告（妥当性・影響範囲・検証観点）を受けてから、implementer に修正を依頼する。
フェーズ3-Aレビュー依頼フォーマット:
reviewer へ:
外部指摘の事前評価をお願いします。
レビューフェーズ: フェーズ3-A（外部指摘受理直後/実装前）
プランファイル: <plan-fileタグのパス>
**外部指摘内容**:
{外部指摘の要約}
**関連ファイル一覧**:
{指摘に関連するファイルパス}
指摘の妥当性評価、影響範囲の特定、修正後の検証観点を報告してください。
3.2 修正サイクル
フェーズ3-Aレビューの評価を踏まえ、フェーズ2と同様のサイクルで修正を実施:
- reviewer の3-A評価に基づき、implementer に修正を依頼（リーダーからSendMessage）→ implementer の修正完了報告を待つ
- reviewer に**フェーズ3-B（修正完了後）**のレビューを依頼 + release-manager にリリース依頼（コミット→PR更新→CI。後続対応はrelease-managerに一任）（並列実行）
フェーズ3-Bレビュー依頼フォーマット:
reviewer へ:
修正完了後のレビューをお願いします。
レビューフェーズ: フェーズ3-B（修正完了後）
プランファイル: <plan-fileタグのパス>
**対象ファイル一覧**:
{implementerの完了報告から変更ファイル一覧を転記}
**元の外部指摘内容**:
{対応した外部指摘の要約}
外部指摘の解消確認に加え、全体再レビューを実施してください。
指摘があれば具体的に報告してください。
3.3 収束判定
ユーザーからの指摘がなくなるまで 3.1〜3.2 を繰り返す。
チーム解散（ユーザーの明示的な指示があった場合のみ）
全タスク完了後もチームは維持し、ユーザーの明示的な指示があるまで解散しないこと。
ユーザーから「解散」等の指示があった場合のみ:
- 各メンバーに感想を求める（SendMessage type: message）
- 今回の作業で感じたこと、改善点等
- 全メンバーの感想が出揃うまで待つ
- 各メンバーにシャットダウンリクエストを送信（SendMessage type: shutdown_request）
- 全メンバーのシャットダウン確認を待つ
- TeamDelete でチームリソースを削除
- ユーザーに完了報告
Converted and distributed by TomeVault — claim your Tome and manage your conversions.