dispatching-parallel-agents

状態を共有せず、順番にも依存しない独立した作業が 2 つ以上あるときです（説明文の条件）。

このスキルの主張は 1 行です。

独立した問題領域ごとに 1 つのエージェントを投げる。同時に走らせる。

要点は速さではなく文脈の扱い

要点は速さではなく、文脈の扱いです。本文の最初がそれを言っています。

専門のエージェントに、隔離された文脈で仕事を委ねる。指示と文脈を正確に組み立てることで、集中を保たせて成功させる。あなたのセッションの文脈や履歴を継がせてはならない。必要なものだけを正確に構築する。これはあなた自身の文脈を、調整作業のために残すことにもなる。

2 つの節約が同時に起きる

つまり2 つの節約が同時に起きます。

文脈の節約のほうが効きます。理由はスキルを入れすぎて重くなる仕組みに書いています。

使う条件と使わない条件を両方書いている

使うとき（本文が挙げる例）

• 3 つ以上のテストファイルが、別々の原因で落ちている
• 複数の部分系が独立して壊れている
• それぞれが他の文脈なしで理解できる
• 調査の間に共有状態が無い

使わないとき

• 失敗が関連している（1 つ直すと他も直るかもしれない）
• 全体の状態を理解する必要がある
• エージェントが互いに干渉する

「1 つ直すと他も直るかもしれない」を先に確かめる

「1 つ直すと他も直るかもしれない」を先に確かめる指示が良いところです。関連している失敗を 3 つに分けて投げると、3 つが同じ場所を直しにきます。

同じ返答の中で投げると並行になる

実装の要点が 1 行で書かれています。

1 つの返答の中で複数の投げ方をすれば並行、1 返答に 1 つなら逐次になる。

当たり前のようですが、ここを外すと「並行のつもりで順番に走る」ので、利点が消えます。

指示の書き方に型がある

各エージェントに渡すものを 4 つ挙げています。

• 範囲1 つのテストファイル、1 つの部分系
• 目標このテストを通す
• 制約他のコードを変えない
• 返すもの何を見つけて何を直したかの要約

実例の指示文は「単にタイムアウトを増やすな」で締める

そして実例の指示文が載っています。失敗しているテストの名前と期待値のずれを列挙し、手順を 3 つ書き、最後に「単にタイムアウトを増やすな。本当の原因を見つけろ」と制約を付けています。

この制約が実務的です。不安定なテストを任せると、たいてい待ち時間を伸ばして「直りました」と言ってきます。

よくある失敗を 4 組で並べている

戻ってきたあとの確認手順がある

投げたら終わりではありません。

1. 各要約を読む
2. 衝突を確認する同じコードを編集していないか
3. テスト全体を走らせる
4. 抜き取りで中身を見るエージェントは体系的な間違いをしうる

4 番目が誠実です。3 つのエージェントが全部同じ勘違いをすることはあります。

サブエージェントを並行で動かせない環境

サブエージェントを並行で動かせない環境では意味がありません。順番に投げることはできますが、それは普通の作業の分割です。

探索的な調査には向かない

本文が「何が壊れているか分からないうちは使わない」と書いています。まず 1 つのエージェントで全体を見るほうが速いです。

同じファイルを触る作業には使えない

本文の「使わないとき」に「共有状態」が挙がっています。3 つのエージェントが同じファイルを編集すると、後から書いたものが勝ちます。

作業そのものを分離したいなら別の手がある

同じ公開元の using-git-worktrees が分岐を別のディレクトリに分ける方法を扱っています。あちらはファイルの分離、こちらは文脈の分離です。併用できます。

1 件の難しい不具合には向かない

分けられないので投げる先が 1 つになります。そちらは diagnosing-bugs のように 1 件を深く追う型が合います。

投げた先のエージェントが何をするかは、このスキルの外

SKILL.md の解析では、外部通信・シェル実行・ファイル操作の記述は見つかっていません。同梱ファイルは 0 件です。

制約を書かないと範囲外を触られる

本文も「制約なし → エージェントが全部を書き換えるかもしれない」と失敗例に挙げています。「本番のコードは変えるな」「テストだけ直せ」を毎回書いてください。

結果の検証は人が見る

本文の確認手順の 4 番が「抜き取りで中身を見る」です。要約を読んで終わりにすると、3 つの変更が噛み合っていないことに気づけません。

確認の型そのものは verification-before-completion が扱っています。

並行の数だけ費用がかかる

3 つ投げれば 3 つ分です。文脈は節約されますが、総量は増えます。 1 つで足りる作業を分けないでください。

本文に Graphviz の図が埋め込まれている

判断の流れを dot 記法で書いた部分があり、環境によっては図として描かれず、そのまま文字で出ます。読めなくはありませんが、そこは飾りだと思ってください。

いくつまで並行に投げられますか

本文は数を決めていません。実例は 3 つです。

判断の基準は数より独立しているかどうかです。3 つが独立していれば 3 つ、5 つが独立していれば 5 つですが、戻ってきた 5 つの要約を読んで衝突を確認する手間も増えます。

失敗が関連しているかはどう判断しますか

本文は「1 つ直すと他も直るかもしれないか」で判断しています。

実務的な確かめ方は、最も分かりやすい 1 件を先に直してみることです。それで他も直るなら関連しています。直らなければ独立です。

エージェントに親の会話を渡してはいけませんか

渡してはいけません。本文が明示しています。

あなたのセッションの文脈や履歴を継がせてはならない。必要なものだけを正確に構築する。

理由は 2 つあります。子が無関係な情報に引っ張られること、そして親の文脈を調整作業のために残すことです。

各エージェントに何を貼ればいいですか

本文の実例が具体的です。

• 対象のファイル名
• 失敗しているテストの名前と、期待値のずれ（「interrupted at を期待したが出ない」）
• 原因の見立て（「タイミングか競合状態の問題」）
• 手順
• やってはいけないこと（「単にタイムアウトを増やすな」）
• 返してほしいもの

エラーメッセージをそのまま貼るのが一番効きます。

同じ公開元の他のスキルと組み合わせられますか

はい。同じ生態系なので前提が揃っています。

• 1 件ずつの調査 …systematic-debugging
• 作業の分離 …using-git-worktrees
• 完了の確認 …verification-before-completion

using-superpowers がこの群の使い方をまとめています。