---
name: run-agent-team
description: コード変更を伴う Issue（新機能・既存機能の変更・バグ修正）を Agent Teams で進めるとき。「チームで進めて」「Agent Teams でやって」等で使う。architect→reviewer→developer→tester→documenter を編成し、タスク依存で順に進め、解散前チェックまで回す。TeamCreate が使えない環境では確認の上 Subagents で代替できる。typo や 1 行の設定変更など軽微な変更はチーム不要。
---

# Agent Teams 進行（run-agent-team）

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

## いつ使う / 使わない

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

## ロール編成

設計ロールは **architect**（旧 designer。UI デザイナーとの混同を避けた名称）。

| 役割 | エージェント | やること | 使う Skill |
|---|---|---|---|
| 設計 | **architect** | 要件整理・アーキテクチャ設計、Issue に設計記載 | （新規立ち上げ時）`new-project-init` |
| レビュー | **reviewer** | 設計の妥当性チェック＋PR コードレビュー（**セキュリティ観点を含む**）。指摘は敵対的検証を通過したものだけを確定 | `adversarial-verify` / `code-review` |
| 実装 | **developer**（×1〜2） | ブランチ作成・コーディング・PR 作成 | `scaffold-*` / `pre-pr-checks` / `create-pr` |
| テスト | **tester** | テストコード作成・品質検証 | `pre-pr-checks` |
| ドキュメント | **documenter** | ドキュメント整備・乖離点検 | `write-readme` / `doc-sync` |

### 規模に応じてスケール

- **標準**: 上記 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）の結果は必ずこの表で報告する:

```markdown
| 観点 | 結果 | 検証者（実装非関与） | 対応 |
|---|---|---|---|
| 設計との乖離 | なし | 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"` を付け、ファイル編集の衝突を避ける。
- **解散前チェック**: 検証用サブエージェントを**新規に**起動する。実装に使ったサブエージェントを SendMessage で再利用しない（「実装に関与していない新鮮なコンテキスト」の要件は新規起動でそのまま満たせる）。
- **失われるものと補い方**: tmux での可視化とメンバー間の直接通信は使えない。lead が各ロールの報告を要約してユーザーに逐次共有し、判断の記録は従来どおり Issue コメント（手順 6）で残す。
- **完了条件の読み替え**: 「必要ロールを起動し、タスク依存を設定した」は「必要ロールを順序どおり起動し、成果物を引き継いだ」と読み替える。それ以外の完了条件はそのまま適用する。

## ルール・コツ

- **順序と依存を守る。** 並行に見えても、設計が確定してからレビュー、レビュー後に実装、を崩さない。
- **lead（メインセッション）の役割**: 編成・タスク依存設定・進行の交通整理・解散前チェック・解散判断。実装そのものは各ロールに任せる。
- reviewer のコードレビューには**必ずセキュリティ観点**（認証/認可の抜け、入力バリデーション、インジェクション対策）を含める。
- reviewer の指摘（設計レビュー・解散前チェック）は `adversarial-verify` を通過したものだけを正式な指摘として扱う。棄却した候補は同 Skill の形式で理由付きで記録する。
- 規約の正は各プロジェクトの `.claude/rules/`（ブランチ運用・コミット規約等）と CLAUDE.md。本 Skill はそれらに沿って進める手順。

## 補足

- ロール構成・人数はプロジェクト規模に応じて調整してよい（小規模は developer 1 体、大規模は QA 追加など）。
- 社名・固有情報をやり取り/ドキュメントに足さない。

## 完了条件

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

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