Agent Army は何をしますか？
2層の並列実行フレームワーク。司令官は最上位モデル（デフォルトではFable、セッションモデルがOpusの場合はOpus）であり、偵察、構成、ブリーフィング、検証といった思考を行います。司令官は、ユーザーが展開時に選択した階層（パワーレベルを参照）の下位モデルの群れを調整します。各レイヤー1エージェントは、（分割されたものではなく）独自のフルコンテキストウィンドウを持ちます。各エージェントはその下にレイヤー2のサブエージェントを生成します。結果として、1つの分割された脳ではなく、多数の独立した脳が同時に実行されます。
Commander (you — Fable or Opus, the session model)
|
|-- Layer 1: Team (3 to 50+, each = own 1M context, L1 tier from power level)
| |-- Agent A (1M) -- Sub-agent A1, A2, ... (L2 tier)
| |-- Agent B (1M) -- Sub-agent B1, B2, ... (L2 tier)
| |-- Agent C (1M) -- Sub-agent C1, C2, ... (L2 tier)
| |-- ... (no cap)
Swarm vs. army: Swarmは1つのコンテキストウィンドウをサブエージェント間で分割します — 1つの脳を分割したもの。Armyは各レイヤー1メンバーに独自のウィンドウを与えます。この違いこそが、このスキルの要点です。
使用する場合
- 多数のファイルにまたがる大規模リファクタリング
- 複数ファイルにわたる色/スタイル/命名/APIの移行
- 広範なコードベース監査（セキュリティ、a11y、パフォーマンス、デッドコード）
- 一括コンテンツ生成または変換
- 同時に実行可能な6つ以上の独立した作業単位があるタスク
使用してはいけない場合
- 6つ未満の独立した作業単位 — 直接実行してください
- 各ステップが前のステップの出力を必要とする、密接な逐次依存関係がある場合
- 単一ファイルの変更
- すべての出力にわたって一貫した作成者の声が必要なタスク（並列エージェントはずれます）
タスクが明確に適合しない場合は、その旨を伝え、軍隊を立ち上げる代わりにインラインで実行することを提案してください。
- すべてのレイヤー1エージェントは、2つ以上のサブエージェントを生成する必要があります。例外はありません。サブエージェントなしでL1エージェントを展開しようとしている場合は、停止して再構築してください。
- 軍隊を静かに縮小してはいけません。ユーザーが選択した階層に一致させてください。逸脱する必要がある場合は、その理由を明示的に述べてください。
2b. モデルを静かにダウングレードしてはいけません。すべてのAgent呼び出しで、ユーザーが選択したパワーレベルに応じて
model:を明示的に指定してください。省略するとセッションモデルが継承され、Max Powerの請求が静かに発生します。 - サブエージェント展開手順は、レイヤー1のブリーフィングの内部に記述します。これらが欠けていると、サブエージェントは決して作成されません。
- エージェントが完了したら報告します：
[Agent N/M complete] name: X files modified, Y flags。 - 軍隊計画を示し、展開前に展開ゲートを通過してください（フルモード）。クイックモードは計画を内部的に構成しますが、それでもゲートを通過する必要があります。
- 各ウェーブ後：ビルドと疑似完了チェックを実行してください（Verifyを参照）。エージェントからの緑のレポートは主張であり、証拠ではありません。
- 「続けて」/「止めないで」= 継続モード：1つのエージェントが完了したらすぐに新しいエージェントを起動します。待ったり、再質問したりしないでください。
軍隊サイズ
開始前に階層を確認してください。この表を提示します：
| Tier | L1 Agents | Total w/ Sub-agents | Est. Tokens |
|--------------|-----------|---------------------|--------------|
| Conservative | 3 | ~9 | ~200-500K |
| Standard | 5-10 | ~15-30 | ~500K-1.5M |
| Aggressive | 10-20 | ~30-60 | ~1.5-4M |
| Maximum | 20-50+ | ~60-100+ | ~4M+ |
| Custom | you pick | you pick | varies |
デフォルトは「とにかく実行」の場合はStandardです。偵察（ステップ3）の後、見つけた内容に基づいて具体的な数を推奨します — 例：「6つのドメインにわたる35ファイル → Aggressive：8つのL1エージェント、それぞれ2〜3のサブエージェント（合計約22、約2Mトークン）。調整しますか？」トークン見積もりは大まかであり、タスクの複雑さに応じてスケールします。
パワーレベル
サイズはエージェントの数を設定し、パワーはモデルを設定します。両方を1つの質問で尋ねてください（AskUserQuestionはうまく機能します — サイズとパワーを1回の呼び出しで2つの質問として）。ユーザーがすでにパワーレベルまたは明示的なモデルを指定している場合は、質問をスキップしてください。
| Power Level | Commander | Layer 1 | Layer 2 | Best For |
|---------------------|--------------------|---------|---------|-------------------------------------------------|
| Max Power | Fable/Opus (session)| Opus | Opus | gnarly refactors, correctness-critical migrations|
| Heavy (recommended) | Fable/Opus (session)| Opus | Sonnet | most large tasks — smart orchestration, fast exec|
| Balanced | Fable/Opus (session)| Sonnet | Sonnet | mechanical migrations with clear patterns |
| Economy | Fable/Opus (session)| Sonnet | Haiku | high-volume, dead-simple find/replace |
ルール：
- 司令官は常にセッションモデル — FableまたはOpus、ユーザーの選択 — であり、委任されることはありません。セッションがSonnetまたはHaikuで実行されている場合は、展開する前にユーザーに切り替えるように伝えてください（
/modelまたはclaude --model fable）：司令官の品質は軍隊の品質の上限です。 - すべての Agent呼び出しでモデルを明示的に指定します：チームメンバーには
model: "<L1 tier>"。L1ブリーフィングはサブエージェントにmodel: "<L2 tier>"を指示します。 - エージェントごとのエスカレーションは任意のパワーレベルで許可されます：重いまたは複雑なファイル（1000行以上、複雑なロジック）は、その1つのサブエージェントを1階層上げることができます。エスカレーションは軍隊計画に記録してください。
- 監査ウェーブはパワーレベルに関係なくOpusで実行 — 実行者に対する新鮮で強力な目。通知ウェーブはHaikuに落とすことができます。
プロトコル
モード： スコープがすでに具体的である場合（ファイルパス、正確な変更、階層）、ステップ3（クイックモード）にスキップします。それ以外の場合はステップ1（フルモード）から開始します。
ステップ1：情報収集（フルモード）
ユーザーがすでにコンテキストを提供している場合は、1行で確認します：「目標：[X]。スコープ：[Y]。階層：[Z]。パワー：[P]。開始します。」それ以外の場合は、以下を尋ねます：目標（1文）、スコープ（ファイル/ディレクトリ/「すべて」）、制約（Xには触れない、Yに一致させる）、階層、パワーレベル。
ステップ2：Gitチェックポイント
git status— コミットされていない変更について警告し、スタッシュ/コミットを提案します。git checkout -b agent-army/checkpoint-{timestamp}を実行後、元のブランチに戻ります。これがロールバックポイントです。- gitリポジトリがない場合？安全策がないことを警告し、明示的な確認を得ます。
ステップ3：偵察
- Grep / Glob / Read を使用して、影響を受けるすべてのファイルを見つけます。
- 作業単位を数えます。
- 各ファイルで
wc -lを実行します。500行以上のファイルは重いとマークし、単独で割り当てます。 - ドメイン（ディレクトリ、インポートグラフ、ファイルタイプ、命名パターンによる）に分類します。
- 共有依存関係 — ドメイン間でインポートされる基盤ファイルを特定します。これらを最初に処理します（ステップ5）。
- ビルドコマンドを特定します（package.json、Makefileなど）。
出力：Files: N | Heavy: [list] | Domains: [list] | Shared deps: [list] | Build cmd: [cmd]
ステップ4：構成
- 共有依存関係のための基盤エージェント — 依存関係が競合しないように、並列ウェーブの前に実行します。
- レイヤー1： ドメインごとに1つのエージェント。大きなドメインは複数のエージェントに分割します。
- レイヤー2： L1エージェントごとに2つ以上のサブエージェント。ファイル数ではなく、重み付きファイル負荷によって割り当てます：
- 小さい（<200行）：サブエージェントあたり2〜3
- 中程度（200〜500）：サブエージェントあたり1〜2
- 重い（500+）：サブエージェントあたり1つ、単独
- すべてのエージェントに名前を付けます。すべてのファイルを正確に1つのサブエージェントに割り当てます — 重複やギャップは許可されません。
軍隊計画を出力します。フルモード：続行するか一時停止します。クイックモード：1行の要約を出力してから展開します。
展開ゲート
展開前に、応答にこのチェックリストを出力します。頭の中でチェックしないでください — 書き出してください。
DEPLOYMENT GATE:
[ ] Every L1 brief contains "You MUST spawn N sub-agents"
[ ] Every sub-agent is named with specific files assigned
[ ] Every file is owned by exactly one sub-agent (no overlap, no gap)
[ ] L1 briefs include full sub-agent deployment instructions
[ ] Tier matches the user's selection
[ ] Power level set: model: "<L1 tier>" on every L1 call; L2 tier + escalations in every brief
すべてがPASSである必要があります。1つでもFAIL → 展開前に計画を修正します。
ステップ5：展開
- 最初に基盤エージェント（存在する場合）をL1階層で実行します。完了を待ちます。
- すべてのレイヤー1エージェントを並列に起動します —
run_in_background: trueとmodel: "<L1 tier>"をすべての呼び出しに指定し、1つのメッセージで行います。 - 各L1エージェントは、そのブリーフィングに従って、L2サブエージェントを並列に生成します。
- 各完了を報告します：
[Agent N/M complete] name: results。
ステップ6：検証
- 再スキャン — 残っている違反がないか、ステップ3の検索を再実行します。
- 疑似完了チェック —
git diff --statを実行し、エージェントレポートとクロスリファレンスします。「完了、Nファイルを修正」と報告したが、一致する差分がないエージェントは、嘘をついたか、何も実行しなかったことを意味します — 再ディスパッチします。レポートではなく、差分を信頼してください。 - ビルド — ビルドコマンドを実行します。PASS/FAILを記録します。
- レポートからチーム間のフラグを解決します。
- 軍隊レポートを出力します：
Agents: N | Files modified: N (diff-confirmed) | Skipped: N | Build: PASS/FAIL
Flags: [list] | Phantom completions caught: N | Rollback: git checkout agent-army/checkpoint-{timestamp}
ウェーブ
各ウェーブは、新しい、より小さく、異なる専門性を持つ軍隊です。各ウェーブの前にユーザーの承認を求めます。最大4ウェーブ。
| Wave | Name | Trigger | Purpose |
|---|---|---|---|
| 1 | Execute | always | make the changes |
| 2 | Audit | build fails, remaining violations, 20+ files, or flags > 0 | fresh agents review Wave 1 for correctness/edge cases |
| 3 | Propagate | changes touch APIs/types/interfaces; tests or docs reference old patterns | update tests, docs, configs, downstream callers |
| 4 | Notify | user opts in | draft PR description, changelog, Slack summary |
各ウェーブのレポートは、次のウェーブの偵察です。各ウェーブの後、Verifyを再実行します。再スキャンがクリーンでビルドが合格するか、4ウェーブに達したら停止します。
再開 / スクラッチパッド
マルチウェーブまたは中断可能な実行のために、ウェーブ1の後に .army-state.md を書き込みます：変更されたファイル（差分確認済み）、未解決のフラグ、未解決の問題、決定事項。実行が強制終了された場合、次の呼び出しはこのファイルを読み取り、最後のクリーンなウェーブから再開し、最初からやり直しません。シングルウェーブタスクの場合はスキップします。
レイヤー1 プロンプトテンプレート
これは、起動されたエージェントが実際に目にするもの — スキルの中で最も重要なセクションです。
You are [AGENT_NAME], specialist on [DOMAIN].
Objective: [one sentence]
Approved patterns: [exact values — hex codes, class names, API shapes]
Forbidden patterns: [what to remove/avoid]
Your files: [absolute paths with line counts]
Rules: [constraints]. Skip files already using approved patterns (idempotency).
Flag issues outside your files in "Flags for Commander" — do NOT fix them.
CRITICAL: You MUST use the Agent tool to spawn the sub-agents listed below. Do
NOT do the work yourself. Do NOT skip spawning. Deploy ALL sub-agents in a single
message with multiple Agent tool calls, passing model: "[L2_TIER]" on every call
[note escalations: except "NAME" which gets model: "[higher tier]"].
Sub-agents:
- "[NAME]": [files with line counts]
- "[NAME]": [files with line counts]
Pass each sub-agent: objective, their files, approved/forbidden patterns, rules,
report format. After all complete, aggregate their reports and verify (by re-reading
or grepping) that no forbidden patterns remain in your domain before reporting back.
レイヤー2 プロンプトテンプレート
You are [SUB_AGENT_NAME], working under [TEAM_MEMBER_NAME].
Objective: [one sentence]
Files you own: [absolute paths with line counts — touch only these]
Approved / Forbidden patterns: [exact values to use and remove]
Rules: [constraints]. Skip files already correct. Flag issues outside your files —
do NOT fix them.
Process: read each file fully → check idempotency → apply approved, remove forbidden
→ re-read to confirm no forbidden patterns remain.
Report: Files Modified (file: N replacements), Files Skipped (already correct),
Flags for Commander, Issues, Status (COMPLETE/PARTIAL/FAILED).
レポート形式
すべてのエージェントは以下を返します：
## Report: [Name]
Files Modified: [file: N replacements]
Files Skipped: [file: reason]
Flags for Commander: [issue or "None"]
Issues: [issue or "None"]
Status: COMPLETE / PARTIAL / FAILED
アンチパターン
これらは、このスキルが防止することを目的とする失敗モードです。自分がこれらのいずれかを実行していることに気付いた場合は、停止して修正してください。
- 疑似ファンアウト — L1エージェントがサブエージェントを生成する代わりに、自分で作業を行ってしまいます。速度の利点がすべて失われます。必須ルール1とゲートによって強制されます。
- 疑似完了 — エージェントが何も編集せずにCOMPLETEを報告します。レポートを信頼するのではなく、
git diff --statのクロスチェックによって捕捉されます。 - 静かな縮小 — ユーザーがAggressiveを選択したにもかかわらず、3つのエージェントを静かに実行します。常に逸脱を表面化させてください。
- モデルドリフト — Agent呼び出しで
model:を省略し、すべてのサブエージェントが司令官のモデルを静かに継承します。ユーザーはEconomyを選択したのに、Max Powerの請求が発生します。必須ルール2bとゲートによって強制されます。 - 所有権の重複 — 2つのサブエージェントが同じファイルを編集すると、競合と編集の損失が発生します。ゲート内の「正確に1つの所有者」によって強制されます。
- 基盤のスキップ — 共有ファイルが更新される前に依存関係に触れると、破損したインポートのカスケードが発生します。基盤エージェントが最初に実行されます。
- 小さなジョブに軍隊を使用 — 4つのファイルに9つのエージェントは（オーケストレーションのオーバーヘッドにより）遅くなり、トークンを消費します。「使用してはいけない場合」を参照してください。
エラーハンドリング
- サブエージェントが失敗 → L1エージェントがファイルを再試行するか、代替を生成します。
- L1エージェントが失敗 → 司令官が同じブリーフィングで代替を生成します。
- ビルド失敗 → チェックポイントブランチとの差分をとって破損を特定し、修正ウェーブを実行します。
- 疑似完了 → そのエージェントのファイルを新しいエージェントに再ディスパッチします。
- 再実行時の冪等性 → エージェントは最初に既存のパターンをチェックするため、軍隊を2回実行しても二重適用されることはありません。
動作例
ユーザー
…
[翻訳のため省略]