mcpField
D
delegation-mode

delegation-mode

github.com/skynight137エージェントワークフロー109 回インストール
リポジトリ

delegation-mode について

delegation-modeは、計画とタスク結果をファイルに保存し、セッションをまたいで作業を再開できるエージェント向けの委譲ワークフローです。大規模で複数段階の作業や、並列化できる作業に適しています。

主な機能

  1. 01計画と結果をファイルに保存
  2. 02タスクごとに固定IDと出力先を指定
  3. 03結果ファイルを検証して完了を確認
  4. 04逐次または並列でタスクを実行
  5. 05確認済みタスクを省いて再開

活用シーン

  1. 01複数のコンテキストウィンドウにまたがる作業
  2. 02独立した分析タスクの並列分担
  3. 03中断後に未完了の作業を再開

インストール

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

$npx skills add https://github.com/skynight137/agent-skills --skill delegation-mode

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

同梱ファイル

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

references/
delegation-modes.md
scripts/
delegation-plan.template.js
plan-validation-core.js

詳細

委任モード

委任モードでは、委任した作業の信頼できる情報源としてファイルシステムを使用します。 チャットの記録は進捗報告に役立ちますが、引き継ぎをそれだけに頼ることはありません。 コーディネーターが実行可能な計画を作成し、各ワーカーが自身の結果を .agents/plans/ に直接書き込みます。その後のセッションでは、同じ計画を再実行し、完了済みのタスク ID をスキップします。再利用可能なランナーは、タスクを完了として確定する前に、ワーカーの応答だけでなく結果ファイルも検証します。

規模が大きい、複数の手順がある、並列化できる、1 つのコンテキストウィンドウを超える可能性がある、または次のエージェントが利用できる永続的な計画として価値がある作業には、このモードを使用してください。永続的な成果物を必要としない小規模な対話形式の回答には使用しないでください。

信頼できる情報源

実行ごとに計画スクリプトを 1 つ使用します。

.agents/plans/
├── YYYY-MM-DD-<slug>.js              # executable dispatcher and resume state
├── YYYY-MM-DD-<slug>-<task-id>.md    # one durable result per task
└── YYYY-MM-DD-<slug>-FINAL.md        # optional aggregation plan

scripts/delegation-plan.template.js を最初のパスにコピーし、プロジェクトのコンテキストとタスク定義を記入してください。スクリプトには次の内容が必要です。

  • 固定された実行日とスラッグ。
  • すべてのタスクに対する、固定された一意の ID。
  • すべてのタスクに対する、正確な出力パス。
  • MODE = "sequential" または MODE = "parallel"。
  • 初期状態では空で、再開時に更新する DONE_IDS。
  • 任意の最終集約タスクを制御する FINAL_DONE。

別のセッションでチャットから振り分けロジックを再構成せずに同じファイルを実行できるよう、計画スクリプトは .agents/plans/ に保存してください。実行前に、すべてのプレースホルダーを埋めてください。計画の DATE、SLUG、タスク ID、出力パスは、その計画の識別情報の一部です。対象範囲が変わった場合は、新しいスラッグを作成してください。

再利用可能なテンプレートは scripts/plan-validation-core.js を読み込みます。このファイルは、計画の識別情報チェック、安全な出力パス、DONE_IDS、Markdown のフロントマター、完了マーカー、永続ファイルの検証を一元的に担います。ローダーは、公開可能なソースツリーとインストール済みスキルツリーをチェックするため、コピーした計画もインストール後に引き続き使用できます。

ワーカーの契約

委任されたすべてのワーカーは、次の条件を満たす必要があります。

  1. タスクのプロンプト全体と、関連するソースファイルを読みます。

  2. 割り当てられた範囲内で作業し、計画で実装の担当が明示されていない限り、アプリケーションのソースを編集しません。

  3. プロンプトで指定された正確な出力パスに、完全な結果を直接書き込みます。

  4. kind: plan、意味のある id、実態に即した status を含む Markdown の計画フロントマターを使用します。完了した結果には status: done を設定し、ブロック中または未完了の結果では完了を主張してはいけません。

  5. 実行可能な調査結果、決定事項、ブロッカー、または実施した変更を記載します。

  6. 結果ファイルの最後の空でない行として、応答にも記載する正確な FILE_WRITTEN: 行を含めます。これにより、ワーカーが書き込みを終えた後、応答が返される前にディスパッチャーが停止しても、結果を監査できます。

  7. 応答の末尾には、次の内容だけを正確に記載します。

     FILE_WRITTEN: <exact-output-path>
    

    結果ファイルが存在し、ファイルチェックに合格した場合に限り、応答マーカーは有効です。応答マーカーは稼働状況を示す有用なシグナルであり、ファイルマーカーは永続的な完了シグナルです。

実装タスクでは、結果計画に、変更内容、影響を受けたファイル、実施した検証、残っているリスク、次のアクションを記録してください。分析タスクでは、対象範囲、根拠、結論、推奨する作業を記録してください。対象範囲を確認し、該当するものがなかったことをワーカーが明示的に記録していれば、結果が空でも有効です。

順次ディスパッチと並列ディスパッチ

デフォルトは順次実行です。

const MODE = "sequential";

ランナーは、次のタスクをディスパッチする前に、保留中の各タスクの完了を待ちます。次の場合に使用してください。

  • タスクが共有リソースを取り合う可能性がある;
  • あるタスクが別のタスクに依存している;
  • ワーカーが重複するファイルを編集する可能性がある;
  • リポジトリまたはツールの予算が限られている;
  • 実行時間の短縮よりも、予測可能な失敗の境界が重要である。

並列実行は、保留中のすべてのタスクが互いに独立している場合にのみ使用してください。

const MODE = "parallel";

並列タスクは、アプリケーションのソースに対して読み取り専用であり、異なる出力ファイルに書き込み、他のタスクの結果に依存しないものでなければなりません。ランナーは Promise.allSettled を使用するため、1 つのワーカーが失敗しても、他のワーカーの結果は失われません。すべてのタスクに検証済みの結果ファイルが揃うまで、集約は実行されません。タスクで dependsOn が宣言されている場合、該当するタスク ID が確認された後に実行する必要があります。並列モードが有効なのは、依存関係グラフ上、独立したディスパッチが可能な場合に限られます。

書き込みを行う委任タスクには、すべて次を使用してください。

config: { $kind: "general" }

完了にファイルの書き込みが必要なタスクでは、調査のみを行うワーカーを使用しないでください。専用のワーカー種別を使用するのは、コンポジションスキルで互換性のあるファイル書き込み契約が明示的に定義されている場合に限ります。

中断後の再開

Code Execution の実行が強制終了されても、ワーカーがすでに書き込んだファイルは無効になりません。トランスクリプトではなく、計画から再開してください。

  1. 計画に記載された出力ファイルを確認します。
  2. 各候補結果が完成しており、計画のフロントマターが正確で、FILE_WRITTEN: マーカーが空でない最終行に正確に含まれていることを確認します。ワーカーの応答がある場合は、それも追加の確認に使用します。
  3. 確認済みのタスク ID のみを DONE_IDS に設定します。ランナーは、不明な ID、重複した ID、古い ID を拒否し、リストにあるすべての出力ファイルを再検証します。
  4. .js の計画全体を再実行します。
  5. ランナーは DONE_IDS をスキップし、不足しているタスクまたは未解決のタスクのみをディスパッチします。
  6. すべてのタスク ID が確認された後にのみ、最終集約を実行します。

ワーカーから応答がないこと、ファイルが不完全であること、または古いチャットメッセージから完了を推測しないでください。結果ファイルが存在しても、完了マーカーまたは必須の内容が欠けている場合は、その ID を DONE_IDS に含めず、そのタスクを再実行してください。レビューの対象範囲が変わった場合は、古い結果を再利用せず、新しいスラッグを作成してください。

DONE_IDS は、スクリプト内のファイルシステムスキャンから推測するのではなく、意図的に明示するようにしています。これにより、再開の判断を監査可能にし、途中で切れたファイルや古いファイルが完了済みとして扱われるのを防ぎます。

より大きなスキルとの組み合わせ

委任モードは実行レイヤーであり、レビュー方法ではありません。より大きなスキルでは、この契約を使用しながら、独自のタスクリストと結果スキーマを定義できます。たとえば、code-review-axes-and-quality は次のように構成されています。

  • 独立した 10 個のレビュー軸を定義する;
  • 軸ごとに安定したタスク ID と 1 つの .agents/plans/ ファイルを使用する;
  • 順次ディスパッチまたは並列ディスパッチに対応する;
  • 10 個すべての軸が確認された後にのみ、重複を排除する最終集約を実行する。

難しいタスクでは、明示的な依存関係を持つタスクに作業を分解し、必要に応じて順次モードを選択してください。また、最後のタスクがチャットのコンテキストに依存するのではなく、先行する計画ファイルを読み取るようにしてください。

失敗と終了状態

結果ファイルは永続的な記録です。フロントマターまたは本文では、次の意味で使用してください。

状態意味
pendingタスクはまだディスパッチされていません。
running作業が進行中です。有用な場合は、途中経過を記録します。
blocked特定の判断、入力、または環境条件が不足しており、安全に進められません。
doneタスクの出力が完成し、検証済みです。

タスクの大部分が完了したというだけで、タスクを done にしてはいけません。計画スクリプトは、未解決のタスクを報告し、いずれかのタスクで例外が発生した場合、またはマーカーがない場合は、最終集約をスキップする必要があります。

最終検証

委任した実行の完了を報告する前に、次のことを確認してください。

  1. 期待されるタスク結果がすべて存在し、.agents/plans/ 内にあり、必須のスキーマに従っていることを確認します。
  2. すべてのタスク ID が DONE_IDS に含まれているか、現在の実行で完了していることを確認します。
  3. 計画で定義されている場合、最終集約ファイルが存在することを確認し、FINAL_DONE = true に設定する前に再検証します。
  4. リンク、フロントマター、git diff --check を確認します。
  5. 実装作業に関連するテスト、リンター、型チェック、またはビルドを実行します。
  6. 検証結果と残っているリスクを最終計画に記録します。

未解決の重大な阻害要因が残っている間は、承認済みと主張しないでください。

同梱リソース

  • scripts/delegation-plan.template.js — 汎用の再開可能なディスパッチャーです。
  • references/delegation-modes.md — モードの選択と再開時のチェックリストです。

コメント