summon-cc

summon-cc — あらゆるエージェントから Claude Code セッションを実行

非推奨です。 summon-cc はアーカイブされており、メンテナンスされていません。後継は conclave (https://github.com/anfreire/conclave) です。1 つの CLI から Claude Code、Codex、または OpenCode のエージェントを起動でき、操作する tmux ペインも必要ありません。 新しい作業ではこちらを推奨します。以下では、現状のこのスキルについて説明します。

あなたはオーケストレーターです。スコープを絞ったプロンプトを渡して、完全な対話型 Claude Code セッション（「ワーカー」） を tmux ペインでデタッチ状態で起動し、追記専用のファイルシグナルを通じて監督します。オーケストレーションはあなたが行い、作業はワーカーが行います。 次の 3 つの原則により、手間をかけず、落ち着いて進められます。

1. ターミナルを解析しない。 すべての情報はシグナルで伝わります。ペインはデバッグ用の 表示領域であり、シグナルが問題を示した場合にのみ読み取ります。
2. アイドル状態でポーリングしない。 ワーカーごとに 1 つの待機プロセスが、何かが起きるまで 無言で待機します。
3. シグナルに基づいて動き、シグナルで確認する。 起動、プロンプト、回答など、すべての操作で、 それが反映されたことを示すシグナルが残ります。スクリプトは自身の手順を検証し、あなたは自分の手順を検証します。

どのハーネス上のどのエージェントでも、オーケストレーターになれます。ここで使う機能はすべて、通常のシェル コマンドです。ワーカー側だけは Claude Code です。それがこのスキルの要点です。このスキルでは、 制限なく、構成要素として Claude Code セッションを利用できます。それを使って何を構築するか （パイプライン、レビューループ、ファンアウト、ウォッチドッグなど）は、あなた次第です。

要件

• Linux または macOS、bash、tmux、jq、および --settings と --effort に対応した claude CLI（現在のバージョンであればどれでも構いません。確認するには claude --help を実行してください）。
• インストールも設定も不要です。 起動時に、各ワーカー用の 6 つのライフサイクルフックが --settings を通じて起動コマンドに注入されます。ユーザーの設定ファイルには一切触れず、 このスキルで起動していないセッションでフックが読み込まれることもありません。
• 2 つのスクリプトは、この SKILL.md と同じ場所にある scripts/ にあります。絶対パスで 実行してください（通常、作業ディレクトリは別の場所です）。以下の <skill-dir> は、この スキルのディレクトリを指します。

クイックスタート — 1 つのワーカーを最初から最後まで実行

brief="$(mktemp)"   # a fresh file per worker
printf '%s\n' 'Fix the failing test in src/foo. END YOUR TURN with a one-paragraph report.' > "$brief"
bash <skill-dir>/scripts/spawn.sh fixer "$brief"
# → SUMMONED id=fixer-6a53bd1e00002f40 state=/home/you/.local/state/summon/workers/fixer-6a53bd1e00002f40
bash <skill-dir>/scripts/wait.sh fixer-6a53bd1e00002f40  # silent until → EVENT=STOP + the report
tmux kill-session -t '=fixer-6a53bd1e00002f40'           # done with it ('=' = exact match)

SUMMONED には 2 つの識別情報が表示されます。id（wait、send-keys、kill で使用）と、state dir（すべてのシグナルファイルを格納）です。以下では、それぞれ <id> と <state> と表記します。すべての操作はこの 2 つを組み合わせて行います。

起動

ワーカーのプロンプトはファイルに書き込みます（複数行の貼り付けは 1 つのブロックとして扱われます）。先頭が /、!、または # で 始まってはいけません。これらは TUI の入力プレフィックス（スラッシュコマンド／bash モード／ メモリー）なので、テキストが送信されず、コマンドとして実行されてしまいます。そのようなファイルを渡すと、起動は明確なエラーを出して拒否されます。それから次を実行します。

bash <skill-dir>/scripts/spawn.sh <name> <prompt-file> [effort] [cwd] [permissions]

• effort — そのまま claude --effort に渡されます。値の種類は claude が定めます （一覧は claude --help を参照してください）。default（既定値）を指定すると、セッション自体の 設定が使われます。設定は反映を待たずに適用されます。不明な値でも中断せず、claude は警告をペインに表示せず、既定値で 実行します。STOP 行には、claude が報告する実効 effort（effort=…）が表示されます。値が適用されたことを確認できるのはここだけです。
• cwd — ワーカーのプロジェクトディレクトリ（既定値：現在のディレクトリ）。
• permissions — bypass（既定値 → --dangerously-skip-permissions。デタッチされたペインでは権限確認に応答できないため、ワーカー自身が判断します。「ワーカーのプロンプト」を参照）・ inherit（フラグなし。claude がその cwd で使う既定値）・それ以外の値はすべて、そのまま --permission-mode に渡されます（モードの一覧は claude --help を参照してください）。無効なモードの場合、起動時に claude 独自のエラーで失敗します。
• SUMMON_CLAUDE_ARGS — 起動コマンドにそのまま追加するフラグを指定する任意の環境変数です。コストを抑えた調査役には --model haiku、終了したワーカーの会話を新しいペインで再開するには --resume <session_id> を指定します（session_id は <state>/events.jsonl にあります）。

起動処理は最初から最後まで自動検証されます（起動、貼り付け、送信のすべてを、独自の再試行を含めてフックのシグナルで確認します）。失敗した場合は理由を明確に示し、ペインの末尾と対処方法を表示します。初回に表示される 2 つの同意ダイアログが、よくある原因です（「落とし穴」を参照）。

ループ

spawn → wait → act on the event → wait again → … → down

bash <skill-dir>/scripts/wait.sh <id> [max_secs]     # default 1800

ハーネスが対応している場合は、バックグラウンドで実行してください（終了するまで何も出力されません）。対応していない場合は、ブロッキングで実行してください。ワーカーの実行中にコストはかからず、終了すると自己完結したブロックが1つ出力されます。

• EVENT=STOP — ワーカーのターンが終了しました。最終メッセージが続きます。Stop フックで取得されるため、トランスクリプトが解析されることはありません。通常は依頼したレポートですが、ワーカーが何かを伝えるためだけにターンを終了することもあります。内容を読んでから、再度確認するか、待ち直してください。Stop の行が読めない場合でも、EVENT=STOP です。ブロックにはメッセージが読めないこととトランスクリプトへの参照先が記載されるため、Stop が IDLE に隠れることはありません。
• EVENT=QUESTION — AskUserQuestion で一時停止しました。番号付きの選択肢が続きます。回答して（次のセクションを参照）、再度待ってください。
• EVENT=IDLE — 上限に達しましたが、何も起きていません。ハートビートの経過時間と最近のツールアクティビティが続きます。長い沈黙は通常のことです（思考中、サブエージェントの実行中、長時間のサブプロセスなど）。同じコマンドを再度実行してください。実際に停止している根拠がある場合にのみ介入してください。
• EVENT=DEAD — ワーカーが終了しました。ペインが強制終了されたか、claude が終了して空のシェルが残っています（どちらかはブロックに記載され、事後確認用の参照先も示されます）。

再度実行するコマンドはまったく同じです。カーソルはワーカーディレクトリ内に保持され、最後に報告されたイベントから再開します。

質問に回答する

選択肢には question.json の順に番号が付いています。ペインは実際の選択肢の後に「何か入力する」「この件についてチャットする」といった独自の項目を追加するため、入力する番号は実際の選択肢に対応しています。

• 質問が1つの場合 — 数字を入力すると選択と送信が行われます：tmux send-keys -t <id> 2
• 質問が複数の場合 — 数字を入力すると自動的に次へ進みます。最後の質問の後、Enter キーで確認ステップを送信します： tmux send-keys -t <id> 1; sleep 1; tmux send-keys -t <id> 3; sleep 1; tmux send-keys -t <id> Enter
• [multi-select] — 数字で選択を切り替え、Enter キーで送信します。
• 自由入力も可能です（「何か入力する」オプション）が、扱いにくいため、一覧から選ぶことをおすすめします。
• 思い込まずに確認してください。 回答が反映されると、選択したラベルを含む QuestionAnswered 行が <state>/events.jsonl に追加され、次の待機で質問の先へ進みます。質問が1つの場合、数字を入力するとすぐに確定され、確認画面は表示されません。そのため、選択が重要な場合は QuestionAnswered 行を読んでください。複数の質問がある場合は、Enter キーで確定する確認画面が最後に表示されます。破壊的な選択肢を送信する前に、内容を確認してください： tmux capture-pane -t <id> -p | tail -30

実行中のワーカーにメッセージを送る

保留中の質問がない場合に限ります（<state>/question.json が存在しない場合）。質問モーダルが表示されている間は、入力したテキストはモーダルに取り込まれ、末尾の Enter でハイライト中の項目が選択されます。そのため、メッセージをキューに入れるつもりが、誤って質問に回答してしまいます。先に質問に回答するか、中断してキャンセルしてください。

• 次のターン境界でワーカーが読み取るフォローアップをキューに入れます（-l は文字どおりに入力する指定です。そのため、Up のような1語のメッセージが、その名前の tmux キーとして送信されることはありません）。 tmux send-keys -t <id> -l 'your message' && tmux send-keys -t <id> Enter
• 長文や引用符の多いフォローアップは、spawn と同じ方法で貼り付けます（ワーカーごとに異なるバッファー名を使うため、並行してメッセージを送っても混線しません）。 tmux load-buffer -b poke-<id> <file> && tmux paste-buffer -t <id> -b poke-<id> -p -d && sleep 1 && tmux send-keys -t <id> Enter
• /、!、# でメッセージを始めてはいけません。これらは TUI の入力プレフィックスであり、入力でも貼り付けでも同じように動作します。/ はスラッシュコマンドを実行します（/exit はワーカーを終了します）。! は続く部分をワーカーの cwd でシェルコマンドとして実行します。# はメモリピッカーを開きます。いずれもプロンプトを送信せず（UserPromptSubmit は発生しません）、リテラルとして入力したい場合は、別の文字で始めてください（例：「注記：/foo …」）。
• 生成を中断して指示を変更するには、tmux send-keys -t <id> Escape を実行してからメッセージを送ります。Escape は TUI 独自の中断キーで、アイドル状態のワーカーでは何も起こりません。ただし、送信は1回だけにしてください。Escape をすばやく2回押すと、シグナルでは検知できない巻き戻しモーダルが開き、コードや会話を復元できる状態になります。メッセージが送信されていないように見える場合（UserPromptSubmit の行が記録されない場合）は、まず Enter をもう一度送信してください。貼り付けに遅延があるとテキストが入力欄に残っていることがあり、Enter をもう一度押せば送信されます（先に貼り付け直すと2つ目のコピーが重なります）。それでも何も起きない場合は、モーダルが表示されています。Escape を1回押して閉じてから、もう一度メッセージを送ってください。 C-c は絶対に押さないでください。C-c をすばやく2回押すと Claude が完全に終了します。停止したように見えるときこそ、実際にはアイドル状態のワーカーに誤って送信しがちです。中断されたターンでは Stop は出力されません。次に完了したターン（送信したメッセージのターン）で出力されます。中断すると保留中の質問はキャンセルされ、孤立した question.json は、次のメッセージが送信された時点で自動的にアーカイブされます。
• 新しく起動したワーカーのコンテキストは空です。ワーカーの作業を続けるには、新たに起動するのではなく、そのペインにメッセージを送ってください。

結果、状態、デバッグ

• 最終メッセージ — STOP 時に wait が出力します。いつでも再確認できます。 grep '"event":"Stop"' <state>/events.jsonl | tail -1 | jq -r .last_assistant_message
• 回答済みの内容 — grep '"event":"QuestionAnswered"' <state>/events.jsonl | tail -1 | jq -c .answers
• すべてのワーカー — find "${SUMMON_STATE:-$HOME/.local/state/summon}/workers" -name meta.json -exec jq -r '"\(.id) \(.name) \(.cwd)"' {} + 2>/dev/null — tmux ls で稼働状態を照合し、保留中の質問は次のコマンドで確認します。 find "${SUMMON_STATE:-$HOME/.local/state/summon}/workers" -name question.json 2>/dev/null.
• 即時プローブ — bash <skill-dir>/scripts/wait.sh <id> 0 はただちに返ります。未消費のイベントがあればそれを返し、なければアイドル状態のスナップショット（ハートビートの経過時間と最近のアクティビティ）を返します。他の wait と同じく、1回限りでカーソルを安全に扱う動作です。プローブにコストはかかりません。
• 覗き見（デバッグ専用 — ペインをキャプチャするたびにオーケストレーターのコンテキストを消費します。通常は上記のシグナルを使ってください）：tmux capture-pane -t <id> -p | tail -40

終了処理

ワーカーの結果を取得したら、tmux kill-session -t '=<id>' を実行します。= は残してください。これにより正確な名前が指定されます。セッションがすでに存在しない場合、-t のみではプレフィックス一致にフォールバックします（注意事項を参照）。Claude のトランスクリプトはディスク上に保持されます。証跡が不要になったら、状態ディレクトリを削除します：rm -rf <state>。ID は再利用されないため、古いディレクトリが衝突することはありません。

ワーカーのプロンプト — オーケストレーションを機能させる要素

• 自己完結型で、範囲が明確です。 ワーカーはあなたのコンテキストを共有しません。目標、正確な作業範囲、対象外の内容を示し、「X と Y は自分で読んでください」と伝えます。ワーカーごとにタスクは1つです。
• 完了方法を伝えます：「A／B／C の報告をしてからターンを終了してください。」停止が完了の合図なので、最終メッセージに必要な事実を含めてターンを終えることも、ワーカーの仕事の一部です。最終メッセージだけで必要な情報がすべて得られるようにします。
• リスクのある操作には自己ゲートを設けます（bypass では必須です）。取り消し不能、破壊的、または範囲外の操作を行う前に一時停止し、AskUserQuestion を使って質問するようワーカーに指示します。これにより、番号付きの選択肢に数字で回答する QUESTION イベントを通じて、判断があなたに回されます。
• 独立したレビューでより多くの問題を見つけられます：パイプラインでは、1人のワーカーに手順を実行させ、新しいワーカーにレビューさせます。変更を加えないレビュアーが承認するまで繰り返します。

判断の振り分け

ワーカーから質問があった場合、タスクの制約からすでに答えが決まっているか、後から戻せる選択であれば、自分で回答して作業を進めます。本当に新規、重大、または取り消し不能なことだけを人間にエスカレーションします。元に戻せるかどうか判断できない場合は、エスカレーションすべきものとして扱います。この境界は事前に人間と合意しておきます。

1つずつ実行する場合とバッチ実行する場合

• 1つずつ実行：起動 → 完了を待つ → 実行 → 停止 → 次へ。各結果が次の手順の前提になります。単純な記録管理に向いています。依存関係のある手順ではこれをデフォルトにします。
• バッチ実行：N 人のワーカーを起動し（名前は別々にし、ワーカーごとに簡潔なファイルを用意します。出力された ID と状態をそれぞれ保持します）、ワーカーごとに1つずつ待機処理を開始します。最初に終了したワーカーを処理し、そのワーカーだけ待機処理を再設定します。シグナルファイルはワーカーごとに分かれているため、並行するワーカー同士が干渉することはありません。ハーネスでバックグラウンド実行ができない場合は、短い上限時間で順番に確認します — wait.sh w1 60; wait.sh w2 60; … — 待機は1回限りでカーソルも安全に扱われるため、順番に確認しても取りこぼしはありません。同時実行数はマシンと注意力で対応できる範囲に抑えます。多数のワーカーを一度に起動すると、claude の起動が spawn の45秒の起動猶予を超える可能性があります。

状態ディレクトリ — リファレンス

ワーカーごとに1つあります：${SUMMON_STATE:-~/.local/state/summon}/workers/<id>/（spawn が出力します）。

ファイル	意味
meta.json	起動した内容：名前、cwd、プロンプトファイル、作業量、権限、追加引数
settings.json	--settings がこのワーカーに注入した内容：6つのフック、promptSuggestionEnabled: false
events.jsonl	ライフサイクル：SessionStart、UserPromptSubmit、AskUserQuestion、QuestionAnswered、Stop（最終メッセージ、権限モード、作業量を含みます）、SessionEnd — イベントごとに1行。ファイル全体があるか、存在しないかのどちらかです
question.json	保留中の AskUserQuestion。存在する == 保留中（回答済み／古いコピーは隣にアーカイブされます）
heartbeat / activity.log	最後のツール呼び出しのエポック時刻／ツール呼び出しごとに1行の帰属情報
claude_exited	終了センチネル：claude が終了した瞬間に、理由を問わずペインのシェルが作成します（起動時にこれがあれば spawn はすぐに失敗します。claude が SessionEnd を記録せずに終了した場合、wait はこれを DEAD として読み取ります — 強制終了、OOM）
cursor	待機処理の記録 — 自動管理されます。触らないでください

注意点

• Stop は完了を示し、SessionEnd は記録処理です — SessionEnd は、終了時に発火する場合もしない場合もあります。正常な /exit では記録されますが、tmux kill-session では記録されることもあり、強制終了では記録されません。意味があるのは記録の有無だけです。決して待ったり、記録がないことから何かを推測したりしないでください。wait.sh はこの仕組みをすべて実装しています。ペインのシェルがまだ動いている状態で claude が終了すると、SessionEnd が発火した場合はそれを介して、発火しなかった場合（SIGKILL、OOM）は claude_exited センチネルを介して、DEAD と判定されます。いつまでも IDLE にはなりません。
• 初回起動時のダイアログで起動が止まります（SessionStart の段階で spawn がエラーを明示して失敗します）。--dangerously-skip-permissions をまだ一度も承認していないマシンや、Claude がまだ信頼していない cwd では、最初に対話型ダイアログが表示されます。対処法は、そのディレクトリで claude を一度対話的に実行して承認し、再度 spawn することです。これらは同意確認の画面なので、スクリプトで回避しないでください。
• バイパスを使わないワーカーは、権限ダイアログで停止することがあります — 権限やプラン承認を求めるプロンプトは AskUserQuestion ではありません。フックは発火せず、シグナルも現れず、ハートビートが古くなるだけです。バイパスを使わないワーカーが IDLE で、ハートビートが古く、保留中の質問がない場合は、ペインを確認してください。send-keys でダイアログに応答するか、バイパスを有効にして再度 spawn してください。
• 語彙はここではなく claude にあります。 努力度と権限モードはそのまま渡され、検証されません。信頼できる情報源は claude --help です。
• ワーカーの入力欄にゴーストテキストは表示されません。 TUI が提案する次のプロンプト（各ターンの後に薄い文字で表示され、ペインのキャプチャでは入力済みのように出力されるもの）は、すべてのワーカーに注入される設定で無効になっています（promptSuggestionEnabled: false）。そのため、ワーカーの入力欄に表示されているテキストは実際のものです。遅れて届いた貼り付け入力か、キューに入った poke です。
• 完全一致する名前が残っていない場合、tmux の -t は前方一致で対象を選びます — その場合、終了済みワーカーの id が、似た名前のセッションに解決される可能性があります。多層防御として、id は固定幅で、spawn は id 形式の文字列を含む名前を拒否します（ある id が別の id の中に入ることはありません。新しいワーカーの name に古いワーカーの id を渡さないでください）。また、ティアダウンのワンライナーでは = を付けて対象を固定します。send-keys／paste／capture でも対象を固定したい場合、ペインを対象とするコマンドには同じ固定方法である -t '=<id>:' を指定してください。
• フックは $SUMMON_ID を条件に実行され、ワーカーごとに注入されます。summon していないセッションが何かを読み込んだり書き込んだりすることはありません。すべてのイベント行が 2 回記録される場合、claude がその cwd 用に読み込む設定ファイルにもフックが登録されています。grep -l on_session_start.sh <cwd>/.claude/settings*.json ~/.claude/settings.json で探して削除してください。それまではシグナルが重複を許容します。
• ワーカーが受け取るのは tmux サーバーの環境であり、あなたの環境ではありません — サーバーは起動したユーザーの環境を保持するため、spawn の前にエクスポートした変数はペインに届きません。ワーカーごとの設定値は起動行（SUMMON_CLAUDE_ARGS）か、注入される設定に指定してください。spawn 自身もこの方法で設定値を渡します。
• スクリプトに GNU 固有の機能を追加しないでください（date -d、sed -i、flock、timeout）。macOS のサポートを維持できるのは、エポック秒の計算と POSIX の基本ツールを使っているためです。