codex-multi-agentlisted

# Multi-Agent Operating Guide 複数 agent を使って作業するときの共通運用ルール。 このスキルの中心はツール依存の操作手順ではなく、次の判断基準にある。 - いつ委譲するか - どう分割するか - 何を並列化してよいか - 主担当がどう統合するか ## Iron Law `今すぐ主担当が自分でやるべき作業は委譲しない` - 直後の意思決定に必要な調査や編集は主担当が自分で行う - サブエージェントには、独立して進められる具体的なタスクだけを渡す - 委譲は目的ではなく手段である。分割すると遅くなるなら分割しない ## 使う場面 - 実装と調査を並列で進めたい - フロントエンド / バックエンド / テストを役割分担したい - 読み取り専用の影響調査を別 agent に切り出したい - レビューや検証を独立した agent に任せたい - 大きなタスクを分割して、最後に主担当が統合したい ## 使わない場面 - 単純な 1 ファイル修正 - すぐに主担当が判断すべき設計変更 - 強く結合した変更で、分割すると手戻りが増える場合 - 「とりあえず並列化したい」だけで、独立タスクがない場合 ## Step 1: 主担当が先に決める 委譲前に、主担当が以下を自分で確定する。 1. ユーザー要求の要約 2. クリティカルパスの特定 3. 並列化できる独立タスクの抽出 4. 自分が今すぐ着手する作業の決定 ここが曖昧なまま委譲しない。 ## Step 2: タスクを分解する サブエージェントに渡すタスクは、次の条件を満たすものだけにする。 - 入力が明確 - 完了条件が明確 - 変更範囲または責務が明確 - 主担当の直後の作業をブロックしない 良い例: - 「`app/admin` 配下でこの UI に関係する既存パターンを 3 点探して報告する」 - 「Laravel 側の既存 API とテスト配置を調査し、変更候補ファイルを列挙する」 - 「この 2 ファイルだけを担当して型エラーを直す」 悪い例: - 「いい感じに全部進めて」 - 「必要そうなものを全部見て実装して」 - 「まず調べて、必要なら設計して、実装して、レビューして」 ## Step 3: 役割を選ぶ まず役割で考え、ツールごとの agent 名は後で割り当てる。 | 役割 | 使いどころ | | --- | --- | | planner | 要件整理、タスク分解、依存関係整理 | | researcher | 既存コード調査、影響範囲調査、読み取り専用分析 | | frontend-dev | UI / コンポーネント実装 | | backend-dev | API / ドメイン / リポジトリ実装 | | database | DB スキーマ、マイグレーション設計 | | tester | テスト設計、テスト追加、検証観点整理 | | debugger | 不具合原因調査、再現条件の切り分け | | reviewer | セキュリティ、性能、品質レビュー | | docs | ドキュメント整備 | | ops | Docker / CI / インフラ運用作業 | 迷ったら: - 調査は `researcher` - 実装は該当ドメインの `*-dev` - テストは `tester` - 計画は `planner` ## Step 4: チーム規模を決める 必要最小人数で始める。人数を増やす基準