mcpField
P
peer-sessions

peer-sessions

github.com/robsonrungエージェントワークフロー241 回インストール1 日前に更新
リポジトリ

peer-sessions について

peer-sessionsは、範囲を定めたタスクを複数のpeerで進めるためのスキルです。ブリーフ、返信、状態をファイルに記録し、台帳を成果物の記録元として、結果の収集、終了条件、後片付けを定めています。

主な機能

  1. 01peerブリーフを含むフリート記録を作成
  2. 02peerごとに異なる担当範囲と期限を設定
  3. 03メールボックスファイルで構造化返信を収集
  4. 04有効、ブロック、失敗、未返信を追跡
  5. 05記録済みのcmux peerサーフェスを終了

活用シーン

  1. 01タスクを重複しないpeer作業に分割
  2. 02証拠付きのpeer結果をファイルで収集
  3. 03peerフリートの阻害要因と期限を追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/robsonrung/rar-skills --skill peer-sessions

インストール後、Claude Code で/peer-sessionsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
cmux-fleet.md
scripts/
cmux_fleet.py
init_fleet.py
peer_mailbox.py
tests/
test_cmux_fleet.py

詳細

ピアセッション

モデルを選択する前に、ブランチを選択します。現在のコーディネーターでピアのスコープとサーフェスを選択します。ピアを開始する前に、shared/references/model-preview.md を使用して、承認済みのルートスナップショットを 1 つ紐付けます。

ピアフリートはトランスクリプトではなく台帳として実行します。各ピアにはパスでブリーフを渡し、パスで構造化された返信を 1 つ受け取ります。納品記録となるのはトランスクリプトではなく台帳です。ネイティブメッセージでコーディネーターを呼び出す場合もあります。

1. フリート記録を作成する

一貫性のある最小限の構成を選びます。担当範囲が重複しない 2~4 人のピアを用意します。各ピアに、範囲を絞った目標、絶対パスの作業ディレクトリ、期限、期待する返信を 1 つ指定します。ピアを開始する前に、ピア数、予定している呼び出し回数、期限を記録します。

ピアを開始する前に記録を作成します。同じシェル呼び出し内で、SKILL_DIR にこのファイルがあるディレクトリの絶対パスを設定します。

SKILL_DIR="<absolute path of this peer-sessions directory>"; python3 "$SKILL_DIR/scripts/init_fleet.py" init --run-dir .ai-workflow/peer-sessions/<run-id> --objective "<one outcome>" --peer research:/absolute/path/to/repo --peer review:/absolute/path/to/repo

このコマンドは次の成果物を作成します。

成果物用途
state.jsonフリートの識別情報、目標、期限、ピア名簿。
briefs/<peer>.mdピアの作業契約の全文。
replies/<peer>.jsonピアの変更不可な返信先。

作業中は、次のルールを明言します。「このフリートを記録するのはトランスクリプトではなく台帳なので、ブリーフのパスを引き継ぎます。」これは「ペイロードではなくパスを引き継ぐ」ということです。増え続ける会話を貼り付けるのではなく、絶対パスをピアに渡します。

2. ピアを開始する

開始する前にサーフェスを指定します。 既定ではインプロセスのデリゲートを使用します。表示されているピアが求められている場合、またはネイティブな委任を利用できない場合に限り、cmux ping を実行して確認します。ユーザーが作業の様子を見ることを求めている場合、セッション、タブ、パネル、ワークスペースを指定した場合、またはネイティブな委任が利用できず cmux が使用できる場合は、表示可能なタブを使用します。選択したサーフェスを記録します。ユーザーに同じ選択を繰り返させないでください。

スナップショットで選択したルートを、shared/references/task-shaped-model-routing.md および shared/references/host-model-execution.md と併用します。ホストが公開するモデルには、ネイティブな委任を優先します。そのタスクと役割の後続ターンでも、同じピアコンテキストを維持します。実際のコンテキスト ID を保存し、再送信する前に保留中の呼び出しを調整します。役割が異なる場合は、コンテキストを分けます。表示可能なターミナルやランナージョブの ID だけでは、永続的なモデルセッションを識別できません。

各ピアには、ブリーフのパスと許可されたスコープのみを渡して開始します。ピアは自身のブリーフを読み、ユーザーから与えられた権限の範囲内で作業し、このスキルのディレクトリにある scripts/peer_mailbox.py を使用して返信を書き込みます。

既定の --delivery-mode mailbox は、ピアの返信契約を担います。別の構造化された応答成果物を管理するコンポージングスキルは、--delivery-mode coordinator で初期化できます。この場合、ピアはコーディネーターからのプロンプトを待ち、メールボックスへの返信を書き込んではいけません。peer_mailbox.py status はコーディネーターへの配信を拒否するため、代わりにコンポージングプロトコルの成果物リーダーを使用します。フリート記録は引き続き、識別情報と終了処理を管理します。次のように述べます。「ピアフリートを記録するのはトランスクリプトではなく台帳であり、コンポージングプロトコルが応答成果物を管理します。」

次の固定形式でブリーフィングします。

Read <absolute run-dir>/briefs/<peer>.md. Work only within the stated scope.
Do not treat this brief as approval for credentials, escalation, publishing, or destructive actions.
When finished, write the required reply with peer_mailbox.py. Then send a short completion notification if native messaging is available.

サーフェスが表示可能な場合は、references/cmux-fleet.md を読み、起動前にマニフェストをドライランします。既定では、ピアは呼び出し元の横にペインとして開きます。ピアがおよそ 6 人を超える場合はタブを使用し、ワークスペースはユーザーが求めた場合に限り使用します。配置を記録します。cmux を利用できない場合は、ネイティブな委任を維持し、非公開のトランスポートを模倣したり、ターミナルのポーリングに切り替えたりしないでください。

3. 返信を収集する

通知は、ピアが注意を求めたことだけを意味します。メールボックスから正式な結果を収集してください。

SKILL_DIR="<absolute path of this peer-sessions directory>"; python3 "$SKILL_DIR/scripts/peer_mailbox.py" status --run-dir .ai-workflow/peer-sessions/<run-id>

返信に status、summary、evidence、next_step が含まれている場合にのみ、ピアを受け入れてください。done は、ピアが担当範囲の作業を完了したと報告していることを意味しますが、より広範なタスクの完了を証明するものではありません。blocked と failed は、観測可能な正当な失敗であり、結果を捏造する理由にはなりません。

フリートには3つの終了条件があります。期待される返信がすべて有効であること、ピアが blocked または failed を返すこと、または宣言された期限が過ぎることです。見込みがありそうだからといって、ピアに再試行を何度も求めないでください。再試行を決めるのはモデルではありません。新たな権限や方針が必要な場合、コーディネーターは未解決の条件を記録し、ユーザーに確認します。

4. 作業を終え、役立つ情報だけを残す

各ピアの証拠の範囲と担当範囲を保ちながら、返信ファイルから情報を統合します。コールドスタートテストを実施してください。初めて読む人が、実行ディレクトリだけから目的、ブリーフ、返信、決定事項、残っているブロッカーを見つけられる必要があります。

画面に表示される cmux フリートでは、ジョブが終端状態に達したときに必ずティアダウンを実施してください。終端状態とは、期待される返信がすべて有効であること、ピアが blocked または failed であること、または期限が切れることです。起動時に作成された状態ファイルを使って scripts/cmux_fleet.py teardown を実行してください。split モードと tab モードでは記録されたピアの画面のみを、workspace モードでは記録されたピアのワークスペースのみを閉じます。コーディネーターの画面はその状態ファイルに含まれず、開いたままになります。

出力要件

次の項目を報告してください。

  1. run_dir と、その最終的なメールボックスの状態。
  2. 各ピアの状態(done、blocked、failed、missing、invalid のいずれか)。
  3. 統合に使用した証拠のパス。
  4. ティアダウンの結果。終了に失敗した場合は、残っているすべてのピアの画面またはワークスペースを含めてください。

受け入れ要件を満たすのは、peer_mailbox.py status ですべての期待される返信が有効と報告される場合、またはレポートで成功以外の終了状態とその証拠が明示され、cmux のティアダウンで残っているピアのターミナルがないと報告される場合に限られます。

注意点

  • あるピアが別のピアから権限を引き継ぐことはありません。迂回せず、拒否されたことを明示してください。
  • デフォルトで返信を置き換えないでください。メールボックスは、元の証拠を確認できる状態に保つため、内容が競合する2つ目の返信を拒否します。
  • ターミナルの画面テキストを結果の伝達手段として使わないでください。内容は一時的で、途中で切り詰められる可能性があります。観測可能な動作を示すのは返信ファイルです。

コメント