Run Agent Team

Agent Teams 進行（run-agent-team）

Issue を Agent Teams で進める段取り。各ロールを編成し、設計→レビュー→実装→テスト→ドキュメントの順にタスク依存で流す。進行役（lead）はメインセッションが担う。

いつ使う / 使わない

• 使う: コード変更を伴う Issue（新機能の追加・既存機能の変更・バグ修正）。
• 使わない（チーム不要）: typo 修正・1 行の設定変更など明らかに軽微なもの。

ロール編成

規模に応じてスケール

• 標準: 上記 5 体。
• 大: developer を 2 体に。
• セキュリティ重要リポ（脅威検出・ハニーポット・認証/IoC 等）: 専任 security を追加し security-review Skill を使わせる。通常は reviewer がセキュリティ観点も兼任する。

手順

1. 対象 Issue を確定する — 無ければ作る。関連 Issue はまとめて 1 チームで対応してよい。
2. 規模を判断する — 軽微ならチームを組まずに対応。そうでなければ編成へ。
3. チームを編成する — Agent Teams（TeamCreate）で必要なロールを起動し、tmux 画面分割で並行作業が見える状態にする。
   • TeamCreate が使えない場合（ツールが利用不可・起動が失敗する等）: 黙って別方式に切り替えず、AskUserQuestion で「Subagents で続行 / 中断して環境を直す」をユーザーに確認する。続行なら下記「Subagents フォールバック」で進め、中断なら失敗内容（エラーメッセージ等）を報告して終了する。
4. タスク依存を張る — 順序を守る: architect（設計）→ reviewer（設計レビュー）→ developer（実装）→ tester（テスト）→ documenter（ドキュメント）。
   • 設計が固まる前に実装を始めない。設計レビューの指摘は architect と調整してから実装へ。
   • 設計レビューは敵対的検証を通す: reviewer は指摘をまず「候補」として出し、adversarial-verify Skill（指摘候補＝設計への指摘 / 対象＝設計文書・Issue 記載 / 基準＝Issue の受け入れ条件・プロジェクト規約）で反証を試み、生き残った指摘だけを architect に返す。反証手順・独立検証の条件・指摘ゼロ時の扱いは同 Skill の定義に従う。
5. 進行を回す — 各ロールは担当 Skill を使って作業する。実装は Issue 連動のブランチで行い、pre-pr-checks を通してから create-pr で PR を出す。main 直 push は禁止。
6. 判断を記録する — 設計判断・調査内容・トレードオフは、チーム内のやり取りだけでなく Issue コメントに残す（後から追跡可能にする）。
7. 解散前チェック（必須） — チームを解散する前に必ず 3 点を検証する:
   1. 設計との乖離 — ドキュメント（CLAUDE.md / README 等）と実装にズレがないか（→ doc-sync）。
   2. テストの不足 — 新規・変更コードにテストが十分か、カバレッジに穴がないか。
   3. ドキュメントの不足 — 新機能・変更がドキュメントに反映されているか（→ doc-sync / write-readme）。
   • 検証は実装に関与していないエージェントが行う（reviewer / tester、または検証用に新規起動したエージェント）。実装した developer 本人の自己チェックで代替しない — 実装の経緯を知らない新鮮なコンテキストの方が、思い込みに引きずられず問題を検出できる。
   • 発見した問題は adversarial-verify で反証を試みてから Issue 化し、対応してから解散する（誤検出を Issue にしない）。
8. 解散する — PR がレビュー済み・マージ可能になったらチームを解散する。

解散前チェックの報告フォーマット

解散前チェック（手順 7）の結果は必ずこの表で報告する:

| 観点 | 結果 | 検証者（実装非関与） | 対応 |
|---|---|---|---|
| 設計との乖離 | なし | reviewer | — |
| テストの不足 | あり: 日付パースの異常系が未カバー | tester | adversarial-verify 通過 → Issue #NN |
| ドキュメントの不足 | なし | reviewer | — |

• 「あり」の行は、adversarial-verify の検証結果（確定/参考/棄却）と対応先（Issue 番号・コミット等）まで書く。

Subagents フォールバック

TeamCreate が使えず、ユーザーが続行を選んだ場合の代替方式。手順・順序・検証の要件は Agent Teams 時と同一で、実現手段だけを置き換える。

• ロール起動: 各ロールを Agent ツールで名前付き起動する（name: "architect" 等、ロール名をそのまま使う）。名前付きなら SendMessage で同じエージェントに追加指示ができ、「設計レビューの指摘を architect に返して調整する」等の往復が成立する。
• タスク依存の代替: lead が手順 4 の順序どおりに各ロールを起動し、前ロールの成果物（設計・レビュー結果・PR 番号等）を次ロールのプロンプトに含めて渡す。順序を崩さない限り、依存関係はこれで担保される。
• 並行作業: developer を 2 体並行させる場合は isolation: "worktree" を付け、ファイル編集の衝突を避ける。
• 負荷の割り当て: 起動時の reasoning effort をロールの性質に合わせる。判断が重いロールには高い effort を割り当てる（architect の設計、reviewer の設計レビュー・コードレビュー、解散前チェックの検証者）。手順が決まっていて機械的なロールは低い effort でよい（pre-pr-checks の実行、定型フォーマットのドキュメント更新）。判断がつかないロールは指定せず、セッションの既定に任せる。
  • モデル名は指定しない。 ロールに合うモデルは環境と世代で変わるため、本 Skill では effort（負荷の高低）だけを指定し、モデルの選択は環境の既定に委ねる。
• 解散前チェック: 検証用サブエージェントを新規に起動する。実装に使ったサブエージェントを SendMessage で再利用しない（「実装に関与していない新鮮なコンテキスト」の要件は新規起動でそのまま満たせる）。
• 失われるものと補い方: tmux での可視化とメンバー間の直接通信は使えない。lead が各ロールの報告を要約してユーザーに逐次共有し、判断の記録は従来どおり Issue コメント（手順 6）で残す。
• 完了条件の読み替え: 「必要ロールを起動し、タスク依存を設定した」は「必要ロールを順序どおり起動し、成果物を引き継いだ」と読み替える。それ以外の完了条件はそのまま適用する。

ルール・コツ

• 順序と依存を守る。 並行に見えても、設計が確定してからレビュー、レビュー後に実装、を崩さない。
• 依存の無い作業は並行させ、lead は待ち時間に止まらない。 設計レビュー通過後なら、developer の実装と tester のテスト設計（設計・受け入れ条件からのテストケース起こし）は並行してよい。テストの実行・品質検証は developer の成果物に依存するため、実装完了を待つ。lead は起動したロールの完了を待つ間、次ロールへ渡す成果物の整理や Issue コメントの記録を進める。脱線・文脈不足に気づいたら SendMessage で介入する。
• lead（メインセッション）の役割: 編成・タスク依存設定・進行の交通整理・解散前チェック・解散判断。実装そのものは各ロールに任せる。
• reviewer のコードレビューには必ずセキュリティ観点（認証/認可の抜け、入力バリデーション、インジェクション対策）を含める。
• reviewer の指摘（設計レビュー・解散前チェック）は adversarial-verify を通過したものだけを正式な指摘として扱う。棄却した候補は同 Skill の形式で理由付きで記録する。
• 規約の正は各プロジェクトの .claude/rules/（ブランチ運用・コミット規約等）と CLAUDE.md。本 Skill はそれらに沿って進める手順。

完了条件

以下を全て満たしたら完了。満たせない項目があれば、黙って省略せず理由を報告する。

• 対象 Issue を確定し、規模判断（チーム要否）を報告した
• 必要ロールを起動し、タスク依存（architect→reviewer→developer→tester→documenter）を設定した（Subagents フォールバック時は同順序での起動と成果物の引き継ぎで代替）
• TeamCreate が使えなかった場合、ユーザーに確認してから Subagents フォールバックに切り替えた（黙って切り替えていない）
• reviewer の設計レビュー指摘が adversarial-verify の検証（確定/参考/棄却の仕分け）を経ている
• 設計判断・調査内容を Issue コメントに記録した
• 解散前チェック 3 点（設計乖離 / テスト不足 / ドキュメント不足）を実装に関与していないエージェントが実施し、報告フォーマットの表で報告した
• 発見した問題を adversarial-verify で検証してから Issue 化し、解散した

補足

• ロール構成・人数はプロジェクト規模に応じて調整してよい（小規模は developer 1 体、大規模は QA 追加など）。使用量・コストの制約が強いときも縮小編成（documenter を reviewer が兼任する等）でよいが、解散前チェック（手順 7）は省略しない。
• 社名・固有情報をやり取り/ドキュメントに足さない。