| name | swarm-dev | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| description | チームを編成して開発する。プロジェクトを探索的に調査し、専門エージェントのチームで修正・テスト・レビューを実施する。 | ||||||||||||||||
| user-invocable | true | ||||||||||||||||
| argument-hint | <タスクの概要 or 修正方針> | ||||||||||||||||
| allowed-tools |
|
複雑な開発タスクを、専門エージェントのチームで並列実行する。
- 「チームを作って直して」「swarm で修正」「全部洗い出して直して」
- 複数ファイル・複数レイヤにまたがる大規模タスク
- CRITICAL/HIGH 問題が複数あり並列対応したい場合
| 優先度 | 定義 |
|---|---|
| CRITICAL | 動作不能・機能が完全に壊れている |
| HIGH | 主要機能が動くが重大な欠陥がある |
| MEDIUM | 軽微な問題・改善余地 |
Implemented → Verified(Local) → Integrated
| ステージ | 条件 |
|---|---|
| Implemented | コードを書いた |
| Verified(Local) | ローカルでテスト通過・動作確認済み |
| Integrated | CI 通過 + （UIタスクのみ）Chrome テスターによる回帰確認済み |
CI 未整備リポジトリでは Verified(Local) + 手動回帰確認 を暫定許容する。
Implemented で止まったままフェーズを進めない。
リーダーはコーディネーションのみ。Phase 1 の調査も含め、実作業は全てサブエージェントに委譲する。
| リーダーがやること | サブエージェントに任せること |
|---|---|
| 要件確認・スコープ判断 | コードベースの発見・調査 |
| タスク分割・割り当て | プロダクト目線での課題発見 |
| フェーズ進行管理 | コードの実装・修正 |
| チーム間の調整 | テストの実行・追加 |
| 最終報告・PR 作成 | CI/Docker の設定・修正 |
| ブラウザ探索的テスト |
コンテキストを実作業で消費すると調整能力が落ちる。迷ったらサブエージェントに渡す。
Phase 0: 要件確認
↓
Phase 0.5: 実行コントラクト確定（Command Detective）
↓
Phase 1: 発見・調査（Discovery エージェント + プロダクトアナリスト 並列）
↓
Phase 2: チーム編成 → Resident Boot Sequence → 即実行開始
↓
Phase 3: CRITICAL修正 → テスト追加 → HIGH修正 → インフラ（各フェーズ自動移行）
↓
Phase 4: 統合・PR作成
$ARGUMENTS を確認し、不明点は AskUserQuestion で聞く。
- タスクの目標: バグ修正？機能追加？品質改善？
- スコープ: CRITICAL のみ？テストも？CI も？
全エージェントが参照する「実行の共通基盤」をチーム編成前に確定する。 Command Detective をサブエージェントとして起動し、以下を調査・実行確認させる。
start_cmd: # ローカル起動コマンド（全サービス）
test_cmd: # テスト実行コマンド
build_cmd: # ビルドコマンド
lint_cmd: # Lint コマンド
typecheck_cmd: # 型チェックコマンド
app_url: # Chrome テスター用 URL（フロントエンドあり時）
env_vars: # 必須環境変数と設定方法
seed_steps: # テストデータ投入手順（あれば）
evidence: # 根拠ファイル（README / package.json / Makefile 等）
verified: # 各コマンドの実行確認結果（成功/失敗）推測禁止。「根拠ファイル + 実行確認」をセットで報告する。 このコントラクトをチーム全員が共有し、コマンド不統一による無駄作業を防ぐ。
リーダーは調査しない。以下の2エージェントを並列起動して結果を受け取る。
- コードベース探索: 主要ファイル・アーキテクチャの把握
- 既存テスト実行: 失敗を洗い出す
- 型チェック・Lint: コンパイルエラー・Lint 違反を確認
- フロントエンドがある場合: ビルドエラー確認
- 発見した問題を CRITICAL / HIGH / MEDIUM に分類して報告
- プロジェクトの目的・ユーザー・ビジネス価値を把握する （README, CLAUDE.md, GitHub Issues, 仕様書等を読む）
- 「本来あるべき機能が欠けている」「動いてはいるが目的を達成できない」問題を発見する
- 技術的には正常でも UX・ビジネス要件として問題がある箇所を洗い出す
- Discovery エージェントとは別視点で CRITICAL / HIGH / MEDIUM を評価して報告
リーダーは両エージェントの報告を統合し、優先度の判断を行う。
問題リストをもとに必要なロールを選んでチームを編成する。
固定ロール（常に起動）
| ロール | 責務 |
|---|---|
| Command Detective | 実行コントラクト調査・確定（Phase 0.5 専任） |
| Discovery エージェント | 技術的問題発見（Phase 1 専任） |
| プロダクトアナリスト | 目的・意義ベースの課題発見（Phase 1 専任） |
| 統合テスト担当 | 既存テスト実行・新規テスト追加・失敗分析 |
| Codex レビュアー | /codex で実装をクロスレビュー（ゲート役） |
| 再帰的プランナー | 計画の見直し・漏れ発見・タスク管理（常駐） |
条件付きロール（機械判定）
以下の条件を Phase 0.5 の実行コントラクトから機械的に評価し、起動を決定する。
| 条件変数 | true の判定基準 |
|---|---|
frontend_present |
package.json に dev/build スクリプトがあり app_url が疎通確認済み |
browser_automatable |
mcp__claude-in-chrome__* ツールが利用可能 |
backend_present |
API サーバ起動コマンドが存在し疎通確認済み |
infra_issue_present |
CI/Docker 関連の失敗が Discovery で再現済み |
| 起動ルール | 起動するロール |
|---|---|
frontend_present=true |
フロントエンド開発者 |
frontend_present=true AND browser_automatable=true |
Chrome テスター（常駐MUST） |
backend_present=true |
バックエンド開発者 |
infra_issue_present=true |
インフラ専門家 |
Phase 2 完了直後に即実行する。待機禁止。 チーム編成後はユーザーへの確認を待たず、この手順を完了してから Phase 3 に移る。
再帰的プランナー（常に起動）:
Skill("loop", "5m 現在の全タスク状態を確認し、計画の漏れ・優先度変化・依存関係の変化を洗い出してリーダーへ報告する。問題なければ「異常なし」とだけ報告する。")
Chrome テスター（browser_automatable=true 時のみ起動）:
Skill("loop", "3m 全主要機能フローを1ラウンド探索し、発見した問題を報告する。既知バグは再報告しない。CRITICAL 新発見時のみ待機、それ以外は即次ラウンドへ。")
- 90秒以内に各常駐エージェントから初回報告を受信する
- 受信できなければ同一設定で再起動（最大2回）
/loopが利用不可ならAgentで定期単発実行に切替- 切替した事実を
TaskUpdateの description に記録する
ロールの詳細な運用ガイドは ROLES.md を参照。
- ファイル単位の予約より 責務境界での分割 を優先する。
- jj を使って並列編集を行う。
# Coordinator がエージェントごとに workspace を作成
jj workspace add ../ws-<agent-name>
# 各エージェントは自分の change で作業
# bookmark: agent/<name>/<task-id>
# 統合: 各エージェント change を integration change に順次 rebase
jj rebase -s <agent-change> -d integration/<task-id>
# → テスト実行 → 通ったもののみ統合
# 統合 change がグリーンになったら main へ反映
# ロールバックは jj op undo で直前操作を戻す- エージェントが最新の integration change に rebase
- 解決できなければ Coordinator が
jj resolveで一元解消 - 同じホットスポットで競合が繰り返す場合はファイル分割・責務分割を検討
チームはユーザー・リーダーの確認なしで、自律的にフェーズを進める。 必要に応じてメンバー間で調整を行う。
Phase A: CRITICAL 修正（並列）
↓ 全タスクが Integrated に達したら自動移行
Phase B: テスト追加（並列）
↓
Phase C: HIGH 修正（並列）
↓
Phase D: インフラ整備（任意）
↓
Phase E: Codex レビュー・統合 → PR 作成
- 全タスクが Integrated 状態
- CRITICAL が新規発生していない（再帰的プランナーが確認）
- Codex レビュアーのゲートチェックが PASS
CRITICAL が未解決のまま次フェーズへ移行しない。
1. 影響タスクを特定: どのタスクの変更が原因か
2. 対象コミット ID を明示してリーダーに報告
3. 他エージェントへの影響を確認（承認必須）
4. jj op undo / git revert でタスク単位で戻す
5. 再帰的プランナーがタスクを再設計してから再実行
他エージェントの変更を承認なく巻き戻さない。ロールバックはタスク単位で行う。
- テスト実行
- Chrome テスター最終ラウンド（
frontend_present=true時） - Codex レビュアー最終ゲートチェック
- コミット・プッシュ
- PR 作成: CRITICAL/HIGH/MEDIUM 別・テスト結果・残課題を記載
アウトプットテンプレートは TEMPLATES.md を参照。
- main への直接 push 禁止 - 必ず feature ブランチ + PR
- 大規模削除・破壊的操作はユーザー確認必須（このルールのみ中断して確認）
- 他エージェントの変更を承認なくロールバックしない
- Integrated 未達のままコミットしない
- CRITICAL は最優先で修正・他フェーズより先に着手
- 実行コマンドはプロジェクトから読み取る（推測禁止）